Último mensaje de la página anterior:
Me fascina este hilo.Toqueteando las tripas del OCS en ASM. Nivel -1
- kikems
- Mensajes: 5502
- Registrado: 30 May 2013 19:23
- Agradecido : 2638 veces
- Agradecimiento recibido: 3112 veces
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Chema escribió:Hey!!! Ahora estoy de vacas y sin equipo para programar a mano, pero esto lo retomo en cuanto pueda!!! GRACIAS
Aqui otra cosa no, pero prisas, tampoco....
Lo proximo será "Fuente C y cookie cut" que se puede resumir en una linea: "Rellenamos lo "negro" de la mascara con la fuente C"
Aun así haré otra intro chustera para que el capitulo quede mas resulton.
Luego un poco por encima como funcionan CLXCON y CLXDAT para las colisiones por hardware (para los que le gustan los juegos) y no se si hacer otro capitulo con otra intro como "recopilatorio" de lo anterior antes de meternos con el DMA de audio.
!Saludos crack!
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
CAP 6h: Fuente C y cookie cut blit
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.
Llegamos a la ultima fuente, la C.
De todas fuentes de origen (ABC), la C es la mas pobre, no tiene registros de mascara, ni tiene desplamiento. Por eso la dejamos para el final.
Si me he explicado bien en capitulos anteriores, esto no deberia ser dificil mas allá de lo que nos queramos complicar con los minterms.
Ya sabemos el concepto de mascara negativa y mascara positiva, teniendo una fuente mas llegamos a esto,el cookie cut.
Con la mascara positiva atrapamos el bob (AB) , con la mascara negativa (-AC) pillamos el fondo, luego se suman y se pintan en D.
De ahi lo de cookie cut (cortar galletas).
Esto nos permite recortar el bob y moverlo sin estopear el fondo. Cosa que antes no podiamos a menos que tiraramos de dual playfield.
Como siempre empezamos con la chuleta:
BLTCON $AFMMB000
Delazamiento de A =$0
Fuentes = ABCD = $F
¿Cual es el minterm en este caso?
La idea es:
1 Donde A sea 0 (neg de la mascara),ignora B y copia C.
2 Donde A sea 1 (pos de la mascara),ignora C y copia B.
Solucion:
La C sale por el nibble azul = 1010 = $A
La B sale por el nibble rojo = 1100 = $C
Resultado $CA
Minterm = $CA
Desplazamiento B = $0
TOTAL BLTCON0 =$0FCA0000
El resto es como siempre, mascara de A,modulos,punteros y escribimos en BLTSIZE.
No he usado desplazamientos porque es un BOB que cuadra a 16 pixels, si no es asi, no podriamos hacer este blit.
Esto lo aprendimos al incio y tambien sabemos como corregirlo, pero ahora que tenemos todas las fuentes y conocemos las limitaciones de cada una, podemos hacer un resumen del blit y ver porque trabajamos de esta manera.
Nuestro bob tiene 16 pixels de ancho (1word), para moverlo tenemos que añadir otro word extra al blit para el desplazamiento.
Al usar ese word extra nos van a entrar restos de otras mascaras, otros bitmaps, etc....
Con la fuente A no hay problema porque BLTAFWM nos permite tapar esos extras.
La fuente B no tiene mascara asi que arrastra la morralla con él.
La fuente C mas de lo mismo
El siguiente paso es el desplazamiento, tanto la A como la B se pueden desplazar, la C no.
Llega el tercer paso, como B no enmascara por si mismo, usamos A.
Ahora podemos sumar el fondo porque no tenemos restos.
¿Se entiende?
Aun queda otro capitulo de video para ojear las colisiones y de paso hacer unos bobs,¿ha quedado la cosa medio clara?
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.
Llegamos a la ultima fuente, la C.
De todas fuentes de origen (ABC), la C es la mas pobre, no tiene registros de mascara, ni tiene desplamiento. Por eso la dejamos para el final.
Si me he explicado bien en capitulos anteriores, esto no deberia ser dificil mas allá de lo que nos queramos complicar con los minterms.
Ya sabemos el concepto de mascara negativa y mascara positiva, teniendo una fuente mas llegamos a esto,el cookie cut.
Con la mascara positiva atrapamos el bob (AB) , con la mascara negativa (-AC) pillamos el fondo, luego se suman y se pintan en D.
De ahi lo de cookie cut (cortar galletas).
Esto nos permite recortar el bob y moverlo sin estopear el fondo. Cosa que antes no podiamos a menos que tiraramos de dual playfield.
Como siempre empezamos con la chuleta:
BLTCON $AFMMB000
Delazamiento de A =$0
Fuentes = ABCD = $F
¿Cual es el minterm en este caso?
La idea es:
1 Donde A sea 0 (neg de la mascara),ignora B y copia C.
2 Donde A sea 1 (pos de la mascara),ignora C y copia B.
Solucion:
La C sale por el nibble azul = 1010 = $A
La B sale por el nibble rojo = 1100 = $C
Resultado $CA
Minterm = $CA
Desplazamiento B = $0
TOTAL BLTCON0 =$0FCA0000
El resto es como siempre, mascara de A,modulos,punteros y escribimos en BLTSIZE.
No he usado desplazamientos porque es un BOB que cuadra a 16 pixels, si no es asi, no podriamos hacer este blit.
Esto lo aprendimos al incio y tambien sabemos como corregirlo, pero ahora que tenemos todas las fuentes y conocemos las limitaciones de cada una, podemos hacer un resumen del blit y ver porque trabajamos de esta manera.
Nuestro bob tiene 16 pixels de ancho (1word), para moverlo tenemos que añadir otro word extra al blit para el desplazamiento.
Al usar ese word extra nos van a entrar restos de otras mascaras, otros bitmaps, etc....
Con la fuente A no hay problema porque BLTAFWM nos permite tapar esos extras.
La fuente B no tiene mascara asi que arrastra la morralla con él.
La fuente C mas de lo mismo
El siguiente paso es el desplazamiento, tanto la A como la B se pueden desplazar, la C no.
Llega el tercer paso, como B no enmascara por si mismo, usamos A.
Ahora podemos sumar el fondo porque no tenemos restos.
¿Se entiende?
Aun queda otro capitulo de video para ojear las colisiones y de paso hacer unos bobs,¿ha quedado la cosa medio clara?
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Jeketerri escribió:pero que maravilla es esta?
En principio era un intento de motivar a la gente a hacer cosillas con el amiga, para el que no tiene ni idea o viene de otras plataformas y quiere ver como funcionan las tripas del OCS.
El tema es que todos estamos faltos de tiempo y no ha terminado de cuajar la cosa. Pero la esperanza de que salgan intros de foreros, aun no la he perdido.
Yo el cacharro lo conozco a base de trastear con el, lo de programar bien es para gente inteligente, no para los que contamos con los dedos.
-
- Mensajes: 6
- Registrado: 03 Jun 2021 18:40
- Agradecido : 3 veces
- Agradecimiento recibido: 4 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Mlake escribió:Jeketerri escribió:pero que maravilla es esta?
En principio era un intento de motivar a la gente a hacer cosillas con el amiga, para el que no tiene ni idea o viene de otras plataformas y quiere ver como funcionan las tripas del OCS.
El tema es que todos estamos faltos de tiempo y no ha terminado de cuajar la cosa. Pero la esperanza de que salgan intros de foreros, aun no la he perdido.
Yo el cacharro lo conozco a base de trastear con el, lo de programar bien es para gente inteligente, no para los que contamos con los dedos.
A mí la idea me parece fenomenal y se agradece mucho, he visto que has incluido un índice el principio, cosa que aún es mejor, el tiempo… eso ya son temas mayores.
- mgyv
- Mensajes: 179
- Registrado: 10 May 2021 21:49
- Ubicación: Vigo
- Agradecido : 157 veces
- Agradecimiento recibido: 107 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Hace un par de días que he visto este hilo. Muy bueno. Ayer estuve viendo hasta el ejemplo 3.
Este finde tengo algo de tiempo, (estoy chungo de una pierna y no puedo salir... no hay mal que por bien no venga, dicen, XD)
¡Gracias por el tutorial!
Este finde tengo algo de tiempo, (estoy chungo de una pierna y no puedo salir... no hay mal que por bien no venga, dicen, XD)
¡Gracias por el tutorial!
A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, +2A
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
mgyv escribió:Hace un par de días que he visto este hilo. Muy bueno. Ayer estuve viendo hasta el ejemplo 3.
Este finde tengo algo de tiempo, (estoy chungo de una pierna y no puedo salir... no hay mal que por bien no venga, dicen, XD)
¡Gracias por el tutorial!
Gracias a ti por el interes.
Cualquier duda (dentro de lo que pueda), por aqui estamos.
Saludos.
- mgyv
- Mensajes: 179
- Registrado: 10 May 2021 21:49
- Ubicación: Vigo
- Agradecido : 157 veces
- Agradecimiento recibido: 107 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Buenas.
Estoy en el ejemplo 6, y es cierto que no he sido capaz de bajar el adf con el material de ejemplo. No tenía ninguna imagen raw, por lo que hice unas líneas con el personal paint y lo he guardado como raw, 320x256, 2 colores.
El código ensambla correctamente, y al ejecutarlo, el bitmap salía descuadrado, no coinciden las líneas y no se ve bien.
Después de hacer pruebas con distintos anchos desde el personal paint, no conseguí que se viera la imagen correctamente.
A continuación, probé a ir cambiando valores de ddfstop hacia arriba y hacia abajo y tampoco conseguí que se viera bien.
Ya desesperado, cambié el ddfstrt por $30 en lugar de $38, y ddfstop por $d8, y conseguí ver el bitmap desplazado unos píxeles (podrían ser 16), casi perfecto.
Luego añadí un dc.w 0, delante del incbin, para que tuviera 2 bytes más el bitmap, y se veía perfecto.....
La duda que me queda es por qué no me funciona con ddfstrt=$38 y ddfstop=$d0.....como dice el HRM...
A todo esto, lo estoy probando en un amiga 500 OCS real, con una TF534, y con un adaptador gary de 1,5mb, kickstart 3.x, wb3.1
Estoy en el ejemplo 6, y es cierto que no he sido capaz de bajar el adf con el material de ejemplo. No tenía ninguna imagen raw, por lo que hice unas líneas con el personal paint y lo he guardado como raw, 320x256, 2 colores.
El código ensambla correctamente, y al ejecutarlo, el bitmap salía descuadrado, no coinciden las líneas y no se ve bien.
Después de hacer pruebas con distintos anchos desde el personal paint, no conseguí que se viera la imagen correctamente.
A continuación, probé a ir cambiando valores de ddfstop hacia arriba y hacia abajo y tampoco conseguí que se viera bien.
Ya desesperado, cambié el ddfstrt por $30 en lugar de $38, y ddfstop por $d8, y conseguí ver el bitmap desplazado unos píxeles (podrían ser 16), casi perfecto.
Luego añadí un dc.w 0, delante del incbin, para que tuviera 2 bytes más el bitmap, y se veía perfecto.....
La duda que me queda es por qué no me funciona con ddfstrt=$38 y ddfstop=$d0.....como dice el HRM...
A todo esto, lo estoy probando en un amiga 500 OCS real, con una TF534, y con un adaptador gary de 1,5mb, kickstart 3.x, wb3.1
A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, +2A
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
mgyv escribió:Buenas.
Estoy en el ejemplo 6, y es cierto que no he sido capaz de bajar el adf con el material de ejemplo. No tenía ninguna imagen raw, por lo que hice unas líneas con el personal paint y lo he guardado como raw, 320x256, 2 colores.
El código ensambla correctamente, y al ejecutarlo, el bitmap salía descuadrado, no coinciden las líneas y no se ve bien.
Después de hacer pruebas con distintos anchos desde el personal paint, no conseguí que se viera la imagen correctamente.
A continuación, probé a ir cambiando valores de ddfstop hacia arriba y hacia abajo y tampoco conseguí que se viera bien.
Ya desesperado, cambié el ddfstrt por $30 en lugar de $38, y ddfstop por $d8, y conseguí ver el bitmap desplazado unos píxeles (podrían ser 16), casi perfecto.
Luego añadí un dc.w 0, delante del incbin, para que tuviera 2 bytes más el bitmap, y se veía perfecto.....
La duda que me queda es por qué no me funciona con ddfstrt=$38 y ddfstop=$d0.....como dice el HRM...
A todo esto, lo estoy probando en un amiga 500 OCS real, con una TF534, y con un adaptador gary de 1,5mb, kickstart 3.x, wb3.1
El ejemplo 6 era para un solo plano, quiza al adaptarlo a 2 bitplanes ha habido algun desliz.
Empecemos:
A la izda tenemos la teoria y a la derecha lo que he entendido en tu mensaje, asi que vamos por partes.....
1º Asegurate del tamaño de la imagen:
320x256x1bpl = 10240bytes
320x256x2bpl = 20480bytes
2º Comprobar si el RAW tiene los bitplanes separados o entrelazados.
La version que tengo de PPaint guarda los RAW con bpls SEPARADOS.
No se si tendrá alguna opcion, pero por defecto los separa.
Recuerda:
ENTRELAZADOS
Bpl1111111111111111111111111111111111111111111
Bpl2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
SEPARADOS
Bpl1111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
Bpl2222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
Si la imagen se ve bien, el problema tiene pinta de venir por los modulos y tú lo has intentado corregir con los DDF. No tiene nada de malo, al reves, significa que el data fetching lo has captado bien.
Aqui te pongo un codigo para repasarlo todo paso a paso
inicio:
apagamos el SO
Nuestra imagen (ejemplo6.raw) tiene 2 bitplanes separados.
El primero está en "BitplaneSEP:" , facil.
BitplaneSEP=BPL1PTx
El segundo hay que calcularlo.
Si los planos estan separados, el segundo puntero está pasado primer bpl al completo, es decir 10240 bytes despues.
Si estuviera entrelazado, el puntero estaria en la linea siguiente (40 bytes despues).
BitplaneSEP+10240=BPL2PTx
Ahora que los punteros estan puestos en la copperlist, la lanzamos y no hacemos nada mas.
COPPERLIST
Apagamos los bitplanes para poder trabajar con ellos con tranquilidad
BPLCON0=$0000
Playfield 320x256
Primero la ventana 320x256
DIWSTRT=$2c81
DIWSTOP=$2cC1
Segundo el DDF para 320 pixels de ancho (40 bytes)
DDFSTRT=$38
DDFSTOP=$D0
Modulos
Pongamonos en situacion y escojamos una linea al azar:
El rayo de la pantalla está pegado al borde izdo, no lo vemos porque está escondido en el overscan. ¿se entiende?
En ese momento DDF es 0 (un poco mas, pero ahora no nos errollemos)
A medida que el rayo corre hacia la derecha, DDF va incrementando.
Cuando llega a DDF=$38, empieza a leer los punteros, pinta pantalla, incrementa puntero, pinta, corre el puntero,pinta..... y asi.
El rayo sigue moviendose a la derecha,DDF incrementa y sigue su rutina repetitiva.
El rayo llega al borde visible que coincide con DDF $D0, paramos de dibujar y se frenan los punteros.
El rayo sigue dentro del overscan pero no hacemos nada.DDF sigue incrementandose.
El rayo toca el borde derecho, DDF llega a su maximo y hay que bajar una linea.
Ocurre el HBLANK. Se reinicia DDF
El rayo sale del borde izdo hacia la derecha, DDF se incrementa.
Llegamos a DDF=$38 y tenemos que volver a pintar.
Bpl1111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
Bpl2222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222
Tus planos estan separados, el MODULO es CERO porque no queremos tocar los punteros.
Que sigan por su camino, que van bien.
BPL1MOD=0
BPL2MOD=0
Si tus planos fueran entrelazados tendrias un "problema"
Bpl11111111111111111111111111111111111111111111
Bpl2222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
1111111111111111111111111111111111111111111111
2222222222222222222222222222222222222222222222
El puntero del plano 1 empezaria a tocar el plano 2 y viceversa.
En ese caso cuando el DDF llegue $D0, frene los punteros y deje de pintar... habria que decirle que ademas les sumara 40 bytes (una linea) y asi no "pisan" lo ajeno.
Lo siguiente son los punteros hacia la imagen, que ya lo vimos antes
BPLxPTH
BPLxPTL
Despues definimos la paleta
COLOR00=$xxx
COLOR01=$xxx
COLOR02=$xxx
COLOR03=$xxx
Encendemos los bitplanes que ya estan configurados
2bitplnes= $2000 + $200(compatibilidad A1000)
BPLCON0=$2200
Fin de la copperlist
$ffff,$fffe
BitplaneSEP el el bitmap 320*256*2bpl
Te dejo la fuente y trasteas con ella. Cualquier cosa comentalo. A veces no me explico muy bien.
- Adjuntos
-
- ejemplo6.7z
- (4.71 KiB) Descargado 30 veces
- mgyv
- Mensajes: 179
- Registrado: 10 May 2021 21:49
- Ubicación: Vigo
- Agradecido : 157 veces
- Agradecimiento recibido: 107 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Gracias por el código de ejemplo. Funciona perfectamente.
Comparando, el problema era el bpl1mod. Lo puse a 0 en la copperlist y ya funciona mi código con 1 bitplane.
Como curiosidad, he visto también, que en la rutina de OSon y OSoff, cuando se guarda y recupera intreq, está 2 veces la línea en las 2 subrutinas.
¿Es realmente necesario ponerlo 2 veces? Lo estoy probando con una sola vez y parece funcionar bien...
Me refiero a las líneas en OSoff:
move.w #$7fff,custom+intreq
Y en OSon:
move.w oldintreq,custom+intreq
Comparando, el problema era el bpl1mod. Lo puse a 0 en la copperlist y ya funciona mi código con 1 bitplane.
Como curiosidad, he visto también, que en la rutina de OSon y OSoff, cuando se guarda y recupera intreq, está 2 veces la línea en las 2 subrutinas.
¿Es realmente necesario ponerlo 2 veces? Lo estoy probando con una sola vez y parece funcionar bien...
Me refiero a las líneas en OSoff:
move.w #$7fff,custom+intreq
Y en OSon:
move.w oldintreq,custom+intreq
A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, +2A
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
mgyv escribió:Gracias por el código de ejemplo. Funciona perfectamente.
Comparando, el problema era el bpl1mod. Lo puse a 0 en la copperlist y ya funciona mi código con 1 bitplane.
Como curiosidad, he visto también, que en la rutina de OSon y OSoff, cuando se guarda y recupera intreq, está 2 veces la línea en las 2 subrutinas.
¿Es realmente necesario ponerlo 2 veces? Lo estoy probando con una sola vez y parece funcionar bien...
Me refiero a las líneas en OSoff:
move.w #$7fff,custom+intreq
Y en OSon:
move.w oldintreq,custom+intreq
Me imaginé que seria algo de modulos.
Cuando aparece la imagen como "a rayas", suele ser por eso.
Sobre lo demas:
Se suele escribir 2 veces sobre INTREQ para dar compatibilidad con los A4000. Si solo escribes una vez, a veces no funciona.
No se si es "fallo" de los A4000 o de los 040/060.
Pasa lo mismo al consultar el estado del blitter, hay que testear dos veces DMACONR si te quieres asegurar.
Otra cosa, al empezar las copperlist siempre es bueno poner FMODE a $0000 (slow fetch) para darle compatibilidad con AGA.
Para el A500 de toda la vida no es necesario.
Cualquier cosa por aqui estamos.
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Cap 7 Denise y Colisiones
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.
El tema de las colisiones viene bien para darle un repaso a cosas viejas, asi que vamos repasar el DMA del OCS.
Espero que ahora sea menos complicado que en la introduccion.
Desde el inicio de linea, las puertas del DMA se van abriendo para que los componentes accedan a la memoria chip, cada bloque/hueco/slot permite pasar 16 bits/1word/2bytes.
Nosotros normalmente declaramos los punteros de nuestras "cosas" (sprites,playfields...) y dejamos que el Amiga trabaje, pero ¿que pasa por dentro?
Esto es un corte de la rutina del DMA, como conocemos el data fetching , nos podemos orientar sobre donde estamos en pantalla. Estamos en el overscan izdo.
Como todavia no hay nada que pintar, se van preparando los sprites.
El ancho del sprite son 16px (1word) con 2 BPL , por eso necesita 2 slots
Esos 2 words son SPR0DATA y SPR0DATB
Cada sprite tiene su SPRxDATA/B.
Una vez el rayo llega a DDF=$38, empeza a cargar los bitplanes (otro slot por cada uno). Asi al llegar a DDF=$40 ya estan listos para pintar y podemos seguir cargado otros 16.
Esos words son BPLxDAT.
Si me he explicado bien, podemos deducir que los graficos del amiga son un puñado de SPRxDATA/B y otro de BPLxDAT
¿Como convertimos esos words en señales para el rayo?
Aqui entra DENISE.
Para generar la imagen, Agnus lee un word (16px) desde los punteros que le damos con BPLxPTH/L (fondos) y SPRxPTH/L (sprites)
Esos words se los envia a denise como BPLxDAT y SPRxDATA/B y se prepara para recibir los siguientes cuando el DDF se lo indique.
El trabajo mas basico para este chip es coger los words, apilarlos (modo planar) y aplicarles el color de paleta que le corresponde a cada pixel.
Esa ristra de pixels (formato 12bitsRGB) la manda al video hybrid para que salga en analogico.
Tambien les aplica la prioridades (dual/single playfield),etc....
Todo esto lo controlamos con BPLCON0 y BPLCON1 (ver lecciones anteriores)
Una de las funciones de Denise es operar con esos words para detectar colisiones entre sprites, entre sprites y fondos/bobs o colisiones entre playfields.
De eso se encargan CLXCON y CLXDAT.
Con CLXCON configuramos con que words queremos operar y en CLXDAT recogemos el resultado de las colisiones.
Por ahora solo quiero que quede claro el camino chipmem-agnus-denise-monitor, despues explicaré como se opera.
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.
El tema de las colisiones viene bien para darle un repaso a cosas viejas, asi que vamos repasar el DMA del OCS.
Espero que ahora sea menos complicado que en la introduccion.
Desde el inicio de linea, las puertas del DMA se van abriendo para que los componentes accedan a la memoria chip, cada bloque/hueco/slot permite pasar 16 bits/1word/2bytes.
Nosotros normalmente declaramos los punteros de nuestras "cosas" (sprites,playfields...) y dejamos que el Amiga trabaje, pero ¿que pasa por dentro?
Esto es un corte de la rutina del DMA, como conocemos el data fetching , nos podemos orientar sobre donde estamos en pantalla. Estamos en el overscan izdo.
Como todavia no hay nada que pintar, se van preparando los sprites.
El ancho del sprite son 16px (1word) con 2 BPL , por eso necesita 2 slots
Esos 2 words son SPR0DATA y SPR0DATB
Cada sprite tiene su SPRxDATA/B.
Una vez el rayo llega a DDF=$38, empeza a cargar los bitplanes (otro slot por cada uno). Asi al llegar a DDF=$40 ya estan listos para pintar y podemos seguir cargado otros 16.
Esos words son BPLxDAT.
Si me he explicado bien, podemos deducir que los graficos del amiga son un puñado de SPRxDATA/B y otro de BPLxDAT
¿Como convertimos esos words en señales para el rayo?
Aqui entra DENISE.
Para generar la imagen, Agnus lee un word (16px) desde los punteros que le damos con BPLxPTH/L (fondos) y SPRxPTH/L (sprites)
Esos words se los envia a denise como BPLxDAT y SPRxDATA/B y se prepara para recibir los siguientes cuando el DDF se lo indique.
El trabajo mas basico para este chip es coger los words, apilarlos (modo planar) y aplicarles el color de paleta que le corresponde a cada pixel.
Esa ristra de pixels (formato 12bitsRGB) la manda al video hybrid para que salga en analogico.
Tambien les aplica la prioridades (dual/single playfield),etc....
Todo esto lo controlamos con BPLCON0 y BPLCON1 (ver lecciones anteriores)
Una de las funciones de Denise es operar con esos words para detectar colisiones entre sprites, entre sprites y fondos/bobs o colisiones entre playfields.
De eso se encargan CLXCON y CLXDAT.
Con CLXCON configuramos con que words queremos operar y en CLXDAT recogemos el resultado de las colisiones.
Por ahora solo quiero que quede claro el camino chipmem-agnus-denise-monitor, despues explicaré como se opera.
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Se me está liando la cosa y me da la sensacion de que me estoy enrollando, solo quiero que quede claro como funciona porque Paula funciona de forma parecida (agnus le manda los words como AUDXDAT).
No se si las cosas van quedando claras y me cuesta horrores escribir. lo mismo acabo colgando Vocaroos.
No se si las cosas van quedando claras y me cuesta horrores escribir. lo mismo acabo colgando Vocaroos.
- mgyv
- Mensajes: 179
- Registrado: 10 May 2021 21:49
- Ubicación: Vigo
- Agradecido : 157 veces
- Agradecimiento recibido: 107 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
Una vez inicializado el framebuffer, aunque sea a 4 colores, necesitaba hacer unas tablas de senos/cosenos, y me he animado a hacer un programita en blitz basic 2 para generarlas. Sé que está la aplicación de windows, Sinus creator (que es muy completa, por cierto), pero me da rabia tener que hacer los archivos en Windows y traerlos al amiga (sobre todo después de ver las últimas retrocriptas de Microsoft de Ron, )
He intentado añadir el código fuente, pero no me deja adjuntar extensión .bb2. Lo dejo en zip, por si a alguien le interesa.
No me deis mucha caña, que es mi primer programa en Blitz....Para compilarlo hace falta el deflibs de 150k del disco de extras. Ah, y solo lo he probado en WB3.1.
download/file.php?mode=view&id=200025046
download/file.php?mode=view&id=200025044
Perdonad por los links e imágenes salpicadas, pero es que no me aclaro cómo ponerlas como yo quiero (voy a tener que practicarlo, también)
Ya volviendo al ensamblador, Sigo en el ejemplo 6. Todavía me cuesta "pensar" en ensamblador, y para ir practicando he hecho una rutina de poner puntos, para poder probar las tablas generadas por el otro programita. Solo es un círculo, pero es la base para poder hacer rotaciones.
download/file.php?mode=view&id=200025047
download/file.php?mode=view&id=200025048
Ah, y tengo unas dudas acerca del asmtwo que me rondan la cabeza...
-Si queda una tabla de dc.w desalineada en ram, ¿hay alguna directiva para que quede en posición par? Es que depende del código que tenga anterior a la tabla, a veces tengo que poner un dc.b delante de la misma.
-¿Cuánto stack tienes en tu programa al lanzarlo desde el asmtwo? Digo porque voy a tener que empezar a usar la pila para guardar registros, etc, y sería interesante saberlo.
-Sería interesante tener un ejemplo de añadir un módulo de protracker y poder tener una rutina para pegar en el código, inicializar, playear, parar, etc
PD: Buff, todo lo que me queda para ponerme al día......
He intentado añadir el código fuente, pero no me deja adjuntar extensión .bb2. Lo dejo en zip, por si a alguien le interesa.
No me deis mucha caña, que es mi primer programa en Blitz....Para compilarlo hace falta el deflibs de 150k del disco de extras. Ah, y solo lo he probado en WB3.1.
download/file.php?mode=view&id=200025046
download/file.php?mode=view&id=200025044
Perdonad por los links e imágenes salpicadas, pero es que no me aclaro cómo ponerlas como yo quiero (voy a tener que practicarlo, también)
Ya volviendo al ensamblador, Sigo en el ejemplo 6. Todavía me cuesta "pensar" en ensamblador, y para ir practicando he hecho una rutina de poner puntos, para poder probar las tablas generadas por el otro programita. Solo es un círculo, pero es la base para poder hacer rotaciones.
download/file.php?mode=view&id=200025047
download/file.php?mode=view&id=200025048
Ah, y tengo unas dudas acerca del asmtwo que me rondan la cabeza...
-Si queda una tabla de dc.w desalineada en ram, ¿hay alguna directiva para que quede en posición par? Es que depende del código que tenga anterior a la tabla, a veces tengo que poner un dc.b delante de la misma.
-¿Cuánto stack tienes en tu programa al lanzarlo desde el asmtwo? Digo porque voy a tener que empezar a usar la pila para guardar registros, etc, y sería interesante saberlo.
-Sería interesante tener un ejemplo de añadir un módulo de protracker y poder tener una rutina para pegar en el código, inicializar, playear, parar, etc
PD: Buff, todo lo que me queda para ponerme al día......
- Adjuntos
-
- EJ06PLOT.S.zip
- (1.63 KiB) Descargado 72 veces
-
- ej06.gif (406.04 KiB) Visto 1715 veces
-
- GENSENO.BB2.zip
- (2.04 KiB) Descargado 64 veces
-
- Genseno.jpg (30.67 KiB) Visto 1715 veces
A2000 [TF534+6mb ZII+opalvision], A500 [ide68k+9.5mb], CD32 [TF330], PiStorm, +2A
- Mlake
- Mensajes: 178
- Registrado: 27 Mar 2019 19:54
- Agradecido : 76 veces
- Agradecimiento recibido: 324 veces
Re: Toqueteando las tripas del OCS en ASM. Nivel -1
mgyv escribió:Una vez inicializado el framebuffer, aunque sea a 4 colores, necesitaba hacer unas tablas de senos/cosenos, y me he animado a hacer un programita en blitz basic 2 para generarlas. Sé que está la aplicación de windows, Sinus creator (que es muy completa, por cierto), pero me da rabia tener que hacer los archivos en Windows y traerlos al amiga (sobre todo después de ver las últimas retrocriptas de Microsoft de Ron, )
He intentado añadir el código fuente, pero no me deja adjuntar extensión .bb2. Lo dejo en zip, por si a alguien le interesa.
No me deis mucha caña, que es mi primer programa en Blitz....Para compilarlo hace falta el deflibs de 150k del disco de extras. Ah, y solo lo he probado en WB3.1.
download/file.php?mode=view&id=200025046
download/file.php?mode=view&id=200025044
Perdonad por los links e imágenes salpicadas, pero es que no me aclaro cómo ponerlas como yo quiero (voy a tener que practicarlo, también)
Ya volviendo al ensamblador, Sigo en el ejemplo 6. Todavía me cuesta "pensar" en ensamblador, y para ir practicando he hecho una rutina de poner puntos, para poder probar las tablas generadas por el otro programita. Solo es un círculo, pero es la base para poder hacer rotaciones.
download/file.php?mode=view&id=200025047
download/file.php?mode=view&id=200025048
Ah, y tengo unas dudas acerca del asmtwo que me rondan la cabeza...
-Si queda una tabla de dc.w desalineada en ram, ¿hay alguna directiva para que quede en posición par? Es que depende del código que tenga anterior a la tabla, a veces tengo que poner un dc.b delante de la misma.
-¿Cuánto stack tienes en tu programa al lanzarlo desde el asmtwo? Digo porque voy a tener que empezar a usar la pila para guardar registros, etc, y sería interesante saberlo.
-Sería interesante tener un ejemplo de añadir un módulo de protracker y poder tener una rutina para pegar en el código, inicializar, playear, parar, etc
PD: Buff, todo lo que me queda para ponerme al día......
Ahora mismo ando en el curro y no me puedo extender mucho. A ver si por la noche tengo un rato y puedo ojear con tranquilidad el codigo.
Lo primero gracias por el programa, en el amiga solia usar el propio asmone para crear las tablas. En cuanto pueda pruebo el tuyo.
Sobre alinear los datos, puedes usar el comando EVEN.
Por ejemplo :
Datos1: dc.b 3,4,8,7,5
EVEN
Datos2: dc.b 5,8
Hemos declarado 5 bytes en Datos1, para que Datos2 no quede en impar, usamos el EVEN.
En tu codigo, vi que has declarado un byte a 0. No se si hacia falta, porque en ese hunk solo esta la copperlist y la imagen de fondo y es dificil que la tabla caiga en impar.
Otra cosa, las tablas las tienes en memoria chip. Podrías pasarlas a memoria fast y asi gastas menos.
En este caso tendrias que poner un EVEN despues de "gfxlib" para que no te caiga en impar y meter ahi las tablas.
O meter las tablas antes y dejar gfxlib al final del hunk.
Sobre el tema del stack, eso lo gestiona el AmigaOS durante el arranque (por defecto tienes 4k en A7). Yo personalmente no uso apenas la pila mas alla de guardar algun registro para no perderlo . Y siempre que he intentado toquetear el tamaño/dirección acabo con cuelgues y problemas.
Por eso directamente paso de usarla.
Sobre el tema de los mod, te puedo preparar un post sobre el P61 si quieres, pero lo suyo es ver primero como funciona paula y despues usar esa libreria para ahorrarnos trabajo. Usarla sin saber como funciona es un poco dar palos de ciego.
Entiendo que cuando empiezas a ver bitmaps en pantalla te den ganas de correr , pero yo te recomiendo primero hacer cosas con el copper y familiarizarte con el DMA, cuando lo tengas dominado empezar con los bitplanes y el audio.
De todos modos por aqui estamos si estás "impaciente" jejeje...
Lo dicho, esta noche le echo un ojo mas a fondo a tu codigo y comentamos la jugada.
Volver a “Software & OS Amiga”
¿Quién está conectado?
Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 4 invitados