Ver la versión completa : Dándole caña a MegaDrive - Necesidad de suite gráfica con opciones de Dithering
masteries
29/07/2021, 13:19
Os lo podéis estar imaginando, trabajando en portar el port de Metal Slug, del STE a MegaDrive
Me encuentro en el punto, de que ya sé cómo cambiar la paleta de color del mapeado cada 8 o 16 líneas...
y estoy descomponiendo los mapas en franjas, de forma que pueda crear una paleta más indicada para cada franja.
Y necesito probar distintos algoritmos de dithering y reducción de color; las AGT siempre emplean el mismo mecanismo, que da
buenos resultados, pero no conviene probar sólo un método. Habrá que probar "ordered dither" y algunos otros,
Para esta tarea Paint Shop Pro se queda muy pequeño, ya que sólo dispone de "diffusion error", y Floyd-Steinberg no da muy buenos resultados
cuando separas en tantas franjas.
¿Qué otros paquetes de software (que no sea Photoshop) me permitirán aplicar un buen repertorio de algoritmos de dithering y que soporten hacerlo en color de 4 bits?
También han de generar ellos la paleta más adecuada, aunque luego a manímetro pueda cambiar alguno de los colores para que lo compartan varias paletas (por los defectos que puedan surgir en alguna imagen, como cambiar demasiado la tonalidad del cielo entre franjas, por ejemplo)
¿No quedara un poco churro en Megadrive por la limitación de la memoria para los tiles/sprites? La prueba mas clara es el Shadow of the Beast, compara el bosque en amiga y en megadrive, no hay color.
https://www.youtube.com/watch?v=y9BltSvKMlQ
https://www.youtube.com/watch?v=PlWEIuiPZa4
-----Actualizado-----
PD: creo que para cosas asi lo mejor es que te hagas una herramienta en la linea de comandos que aplique distintos algoritmos de dithering.
Se me ocurre que uses el imagemagick, es una herramienta por línea de comandos, ideal para procesar por lotes, tiene varios algoritmos de reducción de color y dithering; te puede venir guay para procesar muchas imágenes/tiles al mismo tiempo.
En cuanto al uso, no te preocupes, hay mucha documentación y ejemplos online (en su propia web y en varios foros)
El caso es que ya existen dos proyectos (uno de ellos creo ya debe estar abandonado por viejo) de Metal Slug para mega, no pintan nada mal, lo mismo podrias unir fuerzas con los autores originales, eso seria la leche.
masteries
07/08/2021, 18:19
¿No quedara un poco churro en Megadrive por la limitación de la memoria para los tiles/sprites? La prueba mas clara es el Shadow of the Beast, compara el bosque en amiga y en megadrive, no hay color.
Limitación más gorda es el espacio de color de la MegaDrive, 512 colores frente a 4096 de un STE o un Amiga.
Esto pasa algo más de factura de lo que nos podría parecer,
Si, aunque la PcEngine también tenia 512 colores y como prácticamente los podía mostrar todos en pantalla, los juegos se veían muy coloridos.
masteries
07/08/2021, 19:23
Si, aunque la PcEngine también tenia 512 colores y como prácticamente los podía mostrar todos en pantalla, los juegos se veían muy coloridos.
Es que eso de poder mostrar todos los colores es un puntazo,
sin estar restringido a una paleta por línea de tiles ni cosas así...
Pero bueno, es el punto más flaco de la Mega; (también algunos colores tienen una tonalidad un poco rara)
también se podría comparar con el ST/E, y el truco de duplicar todo en memoria para hacer malabarares con dos paletas de 16 colores xD eso si que es difícil
Bueno, en verdad tienes 32 paletas de 16 colores, por lo que puedes mostrar casi todos los colores, pero al estar agrupados por paletas no puedes hacer la combinación que quieras en un sprite.
fbustamante
08/08/2021, 13:40
Pero, ¿Las paletas son fijas o se puede formar la que uno quiera a partir de esos 512 colores?
masteries
08/08/2021, 18:27
Pero, ¿Las paletas son fijas o se puede formar la que uno quiera a partir de esos 512 colores?
Formas la paleta que desees, escogiendo de entre esos 512 colores.
Realmente, la verdadera limitación viene de que esos sistemas están diseñados (a nivel HW) para guardar y recuperar los datos gráficos en color de 4 bits, 2 pixels por byte.
Luego ya, si dispusieras de más memoria de vídeo podrías descomponer cada tile en dos tiles, y dibujar tiles de 32 colores.
También, más difícil porque no hay htas que te ayuden, componer los mapas con tiles en los que unos usen una paleta, y otros tiles otra, con una distribución homogénea de los tiles (vamos que no te basas en partir el mapa en dos partes bien diferenciadas). Hacer eso a mano sería la locura máxima. xD
Los mapas de NeoGeo están hechos así, cada tile también está restringido a 16 colores; pero maneja muchas paletas a la vez, y los mapas se componen de multiples capas (virtuales) y cada capa de 16 colores.
?Hay algún software que haga eso de forma automática?
Son modificables, naturalmente.
Por ejemplo imagínate que la paleta es de 256 colores de 16millones posibles, los sprites solo tienen 16 colores, entonces la paleta es como si fueran 16 paletas de 16 colores, o sea, tu dices este Sprite va con la paleta 0 y usara los colores del 0 al 15, este otro sprite usara la paleta 4, pues usara los colores del 64 al 79, etc.
En una vga tienes 256 colores y los puedes usar como te de la gana, aquí como va todo por sprites o tiles, eliges que grupo de 16 colores/paleta usar, tiene el inconveniente de que te limita a la hora de usar los colores pero los gráficos te ocupan la mitad de memoria, 4 bits por pixel en vez de 8bits.
-----Actualizado-----
?Hay algún software que haga eso de forma automática?
No creo, aunque en la neogeo al tener tantas paletas podrías descomponer cada nivel en columnas de tiles, en pantalla solo habrá 20 + 1 columnas como mucho por lo que con reservar 21 paletas como mínimo seria suficiente y las puedes ir cambiando a medida que avanzas. Eso si el juego es como el metal slug que solo avanzas.
mills332
06/09/2021, 19:41
Que chulo, yo hice alguna cosa con mega drive, hay un compilador llamado sgdk muy bueno.
Para hacer más colores, al ser una consola que se supone se juega en TV CRT, podrías simplemente dibujar los objetos alternando colores en patrones horizontales, y que el crt o el filtro del emulador haga el truco, es lo que hacian casi todos los juegos, yo no me complicaría demasiado, con eso puedes hacer hasta transparencias. Si conectas una mega drive al lcd, pues no se ven, igual que en los juegos clasicos, es que si no, gastaras mucha memoria creo yo..
Mega Drive tiene en realidad 4 paletas (64 colores que seleccionas de.. no se, muchos), todos ellos los puede usar el fondo, pero hay un límite de 16 colores dentro de cada caracter o tile de 8x8 píxeles, hay herramientas que reorganizan los colores de los tiles de esa manera.
Los sprites ya lo dijeron, cada uno solo utiliza 16 colores.
Yo dejaría 3 paletas para los fondos, y una para los sprites, la verdad es que tienen colores bastante monotonos, no se notaría mucho si todos los sprites usaran la misma paleta.
Mega Drive tiene en realidad 4 paletas (64 colores que seleccionas de.. no se,m muchos), todos ellos los puede usar el fondo, pero hay un límite de 16 colores dentro de cada caracter o tile de 8x8 píxeles, hay herramientas que reorganizan los colores de los tiles de esa manera.
De 512 colores, como en un ST sin la 'e' o una PC-Engine
¿Habéis visto esto?:
https://www.youtube.com/watch?v=e8WcbBsZSjg
masteries
14/09/2021, 13:33
Mega Drive tiene en realidad 4 paletas (64 colores que seleccionas de.. no se, muchos), todos ellos los puede usar el fondo, pero hay un límite de 16 colores dentro de cada caracter o tile de 8x8 píxeles, hay herramientas que reorganizan los colores de los tiles de esa manera.
Pues espero puedas ilustrarnos, porque las htas. más o menos caseras o scene que hemos estado probando; no hacen eso e incluso fracasan para lo básico.
Sería genial que hubiera una herramienta, que le dijeras: -Puedes crear hasta 2 - 3 paletas, ya sabes que cada celda de 8x8 sólo puede utilizar una de las dos paletas.
Y que te administrara los tiles para encajarlos en una paleta u otra.
Puede que os interese esto
https://twitter.com/_fabdigital_/status/1439256580873195523
masteries
19/09/2021, 16:38
Puede que os interese esto
Para ajustar alguna paleta puede servir,
pero para mapeados... sólo puede cargar una imagen de 1000x1000 píxeles, en cuanto alguna de las dimensiones sea mayor ya no la carga.
También puede convertir una imagen enorme, a colores MegaDrive, hasta 512 colores; pero no lo hace respetando la limitación de 16 colores por tile...
Tengo la sensación de que se queda incompleta, como el resto de htas. scene para MD que se han probado...
De todas formas, gracias
mills332
24/09/2021, 17:37
Para ajustar alguna paleta puede servir,
pero para mapeados... sólo puede cargar una imagen de 1000x1000 píxeles, en cuanto alguna de las dimensiones sea mayor ya no la carga.
También puede convertir una imagen enorme, a colores MegaDrive, hasta 512 colores; pero no lo hace respetando la limitación de 16 colores por tile...
Tengo la sensación de que se queda incompleta, como el resto de htas. scene para MD que se han probado...
De todas formas, gracias
Tienes razón, es difícil, yo probé el "retro graphics toolkit", no se si acepta imagenes grandes, creo que tampoco... y además las convierte dejando un dither pero muy feo, muy lleno de ruido. Tal vez usando una aplicación para generar primero los tiles, y luego con los tiles ya generas las paletas con otra aplicación. No se que tal es esa que han puesto aquí, lo probare luego.
Con la potencia de calculo de los ordenadores de ahora tal vez se pueda programar una herramienta que busque la mejor conversion a lo burro.
mills332
25/09/2021, 11:15
Con la potencia de calculo de los ordenadores de ahora tal vez se pueda programar una herramienta que busque la mejor conversion a lo burro.
El único programa que lo intenta hacer es ese retro tool kit, y no lo hace nada bien. Hay otro que es de pago llamado "pro motion" (pude conseguir una especie de demo), afirma que convierte imagenes a tiles con limitaciones para cada sistema, pero no lo hace, simplemente te dice si un tile se sale de las limitaciones o no, pero tu lo tienes que corregir.
No se me ocurre ni como hacerlo automaticamente sin tener que editarlo después. Recuerdo intentar un programa que decia hacerlo para game boy color, y fallaba muchisimo, al final terminabas antes a mano. Me parece que la mega drive es una de esas máquinas en las que o le dedicas tiempo y empiezas a dibujar los tiles desde cero, o te aguantas con 16 colores. Lo más fácil que se me ocurre hacer, es convertir un fondo a 32 colores (para no volverse loco usar solo dos paletas), y luego ir asignando una u otra a cada tile.
Sigue avanzando:
https://www.youtube.com/watch?v=iLzS4_5m7L0
Aparte de enseñar los progresos, en cada video el colega explica un poco cómo va haciendo las cosas y cómo va resolviendo los problemas que va encontrando.
josepzin
06/12/2021, 14:45
el colega explica un poco cómo va haciendo las cosas y cómo va resolviendo los problemas que va encontrando.
Se aprende muchísimo de este tipo de videos.
No se, yo creo que ese SOTN para megadriva nunca va a llegar a nada, o en todo caso a un juego totalmente distinto. Una cosa es programar las cosas por separado y otra muy diferente es poder juntarlas todas, que funcionen, hacer un juego que pueda mover la megadrive con todo eso y hacer que quepa en un cartucho
No se, yo creo que ese SOTN para megadriva nunca va a llegar a nada, o en todo caso a un juego totalmente distinto. Una cosa es programar las cosas por separado y otra muy diferente es poder juntarlas todas, que funcionen, hacer un juego que pueda mover la megadrive con todo eso y hacer que quepa en un cartucho
Ya se estan viendo cosas absolutamente brutales desde hace mucho en la Mega, y solo hablo de juegos completos, no creo que tenga ningun problema en seguir adelante.
Hombre, por temas de espacio, no sé hasta qué punto los gráficos ocupan tanto que, comprimidos, no quepan en un cartucho grande de MD. El SotN tiene muchos diálogos y efectos sonoros (aparte del sonido en CD), pero en cuestión visual... al menos en lo que respecta a tiles, lo mismo es posible que quepa todo. Ya los enemigos grandes o los fondos es otro cantar, pero a las malas, puede hacer como hace todo el mundo, y pasar el desarrollo a Mega CD: es el comodín cuando un proyecto crece demasiado :D
De momento a ver hasta dónde llega.
Hombre, por temas de espacio, no sé hasta qué punto los gráficos ocupan tanto que, comprimidos, no quepan en un cartucho grande de MD. El SotN tiene muchos diálogos y efectos sonoros (aparte del sonido en CD), pero en cuestión visual... al menos en lo que respecta a tiles, lo mismo es posible que quepa todo. Ya los enemigos grandes o los fondos es otro cantar, pero a las malas, puede hacer como hace todo el mundo, y pasar el desarrollo a Mega CD: es el comodín cuando un proyecto crece demasiado :D
De momento a ver hasta dónde llega.
En megaCD lo veo posible; o incluso se me ha ocurrido que podrían hacer como con los cartuchos multijuego, que cada zona del castillo sea un juego diferente y cambien de banco de memoria en las pantallas de transición.
En megaCD lo veo posible; o incluso se me ha ocurrido que podrían hacer como con los cartuchos multijuego, que cada zona del castillo sea un juego diferente y cambien de banco de memoria en las pantallas de transición.
El Demons Of Asteborg son 116 Megas (14.5 megabytes), no veo problemas en el espacio tampoco.
El Demons Of Asteborg son 116 Megas (14.5 megabytes), no veo problemas en el espacio tampoco.
El sotn de play pesa muchísimo más que eso.
El sotn de play pesa muchísimo más que eso.
Venga, pues no sale, que Chipan sabe mas que los que estan sacando juegos homebrew XDDD
Hombre, por temas de espacio, no sé hasta qué punto los gráficos ocupan tanto que, comprimidos, no quepan en un cartucho grande de MD. El SotN tiene muchos diálogos y efectos sonoros (aparte del sonido en CD), pero en cuestión visual... al menos en lo que respecta a tiles, lo mismo es posible que quepa todo. Ya los enemigos grandes o los fondos es otro cantar, pero a las malas, puede hacer como hace todo el mundo, y pasar el desarrollo a Mega CD: es el comodín cuando un proyecto crece demasiado :D
De momento a ver hasta dónde llega.
Si comprimes los gráficos no podrás cargarlos a la VRAM usando el DMA y eso limitaría a la hora de poder tener mas animaciones en los personajes.
En megaCD lo veo posible; o incluso se me ha ocurrido que podrían hacer como con los cartuchos multijuego, que cada zona del castillo sea un juego diferente y cambien de banco de memoria en las pantallas de transición.
Creo recordar que habían juegos que hacían algo así con los mappers: repetían toda la lógica del juego en todos los chips, y los gráficos comunes, pero cada uno de ellos contenía el tileset de una serie de zonas y los gráficos específicos de estas, de forma que se cambiaba de chip ROM "al vuelo" y así parecía que cambiaban los gráficos contenidos en el cartucho.
Si comprimes los gráficos no podrás cargarlos a la VRAM usando el DMA y eso limitaría a la hora de poder tener mas animaciones en los personajes.
Ah, no sé cómo va el uso del DMA. Sé que se han usado gráficos comprimidos en otros juegos, e incluso chips que los descomprimen desde el propio cartucho (¿Street Fighter 2?). Si el problema es con las animaciones, pues sólo se comprimen tiles y gráficos no animados, que hay unos cuantos, si no, la gran mayoría, y así caben más.
Lo más seguro es que haya que limitar el número de animaciones y hacer recortes.
Los canales de DMA son un memcpy implementado por hardware, por lo que va a todo lo que puede dar el ancho de banda de la memoria, no se pierde tiempo ejecutando instrucciones, ni incrementando punteros, ni decrementando contadores para ver si has terminado.
Los canales de DMA son un memcpy implementado por hardware, por lo que va a todo lo que puede dar el ancho de banda de la memoria, no se pierde tiempo ejecutando instrucciones, ni incrementando punteros, ni decrementando contadores para ver si has terminado.
Sí, eso lo sé. Lo que digo es que no sé cómo va el DMA en la MD, si tiene algún tipo de instrucciones concretas, o unas direcciones específicas o unos datos. O si se puede programar para que haga alguna descompresión sencilla.
Es un memcpy no puede hacer ningún tipo de descompresión, tienes unos registros donde le dices la dirección fuente, la destino, el numero de bytes, y por alguna parte también le dices como incrementar los punteros, si quires puedes escribir todo el rato en la misma direccion.
SplinterGU
10/12/2021, 19:03
para graficos en equipos antiguos se suele usar compresion RLE, que es muy simple y rapida... no se lo del DMA y la VRAM en la MD en concreto, pero eso no impide que tengas graficos comprimidos que descomprimas en RAM antes de pasarlos a la VRAM...
Venga, pues no sale, que Chipan sabe mas que los que estan sacando juegos homebrew XDDD
No hombre, me refiero a que la manera que tienen de ir enseñando su progreso pasito a pasito y tan fragmentado, me transmite la impresión de que el/los DEVs implicados no tienen mucha experiencia en el desarrollo para megadrive y que por eso, es posible que en algún momento se puedan encontrar un problema técnico que no puedan resolver. No afirmo nada, es solo que tengo esa sensación y se agrava un poco más por lo grande que es el juego que quieren recrear.
masteries
11/12/2021, 00:36
Sí, eso lo sé. Lo que digo es que no sé cómo va el DMA en la MD, si tiene algún tipo de instrucciones concretas, o unas direcciones específicas o unos datos. O si se puede programar para que haga alguna descompresión sencilla.
No sólo son un memcpy hardware; los canales DMA acceden al cartucho y RAM, cuando el bus está libre. Cuando la CPU no está utilizando el bus de memoria. Eso es así con todos los DMAs, desde MegaDrive, microcontroladores, hasta los PCs que tenéis delante.
Recordad que en estas máquinas, la RAM era aún mucho más rápida que la CPU y los adaptadores de vídeo y sonido; y por eso metieron DMAs, blitter, sprites hardware todo cuanto pudieron. Para aprovechar el tiempo que estaba libre la RAM. Esta manera de diseñar computadores encuentra su límite técnico en el Falcon de Atari.
En MegaDrive la RAM pese a ser más lenta que en un ST, tiene mayor ancho de banda; al ser toda RAM estática y no necesitar refresco (se ahorraron la circuitería y la lógica para refrescar, que no es nada sencillo, a costa de una RAM más cara). Quizá por eso acabaron dejando la VRAM en sólo 64 KB, porque al ser SRAM es más cara. Por cierto, que el VDP funciona a 13 MHz, y cuando construye un fotograma, pinta los sprites línea a línea... la memoria donde el VDP construye la información de la línea (es interna al VDP, hay espacio para dos líneas, la que pintas, y la que sale por el vídeo) para que a continuación la pinte en pantalla el DAC de salida de vídeo, es de 256 bits a 8 MHz (éste dato si me ha parecido sorprendente).
Las capacidades DMA se encuentran sólo en el adaptador de vídeo, el VDP; tiene una caché de instrucciones de 256 bytes. Puedes organizartelo para que sea todo instrucciones relativas a transferencia DMA, para que se encadenen ellas solitas; siendo el resultado final más potente y complejo que un sólo memcpy; es como encadenar múltiples memcpy. Como recomendación, no exceder 200 tiles por frame.
Los gráficos, cuando están comprimidos; deben ser transferidos del cartucho a la RAM del 68000 (éste trabajo lo hace el 68000), el 68000 lo descomprime tile a tile en su propia RAM, y escribe la órdenes DMA en la caché del VDP; el VDP empieza a copiar a la VRAM mientras el 68000 aún sigue descomprimiendo tiles.
Por supuesto, no es muy recomendable utilizar compresión ni para animaciones ni para el mapeado; salvo que el mapeado avance muy lentamente; o vayas a hacer grandes cambios de tiles en la VRAM y se vayan a quedar ahí bastante tiempo.
La compresión en el sonido es bastante útil ;)
Gracias a esto último, la Misión 1 del port de Metal Slug de Atari STE, cabe en tan sólo 1 MB en su versión MegaDrive.
Y a lo que comentaba Chipan; hay unos marrones muy gordos respecto al adaptador de vídeo de MegaDrive; sobretodo cuando utilizas sprites estáticos (todos los frames cargados en la VRAM) y a cómo gestionas los procesos / sprites que se van viendo en pantalla...
por poner un ejemplo: como un sprite alguna vez sólo dure 1 fotograma... ya puedes rezar, porque hacen falta varias pasadas de los datos de un sprite a través de la lógica del VDP en frames sucesivos; en este ejemplo se producirían bugs gráficos y atascos del bus de memoria (con retardo, para confundir más si cabe) provocados por un malfunciomiento del VDP y es irrecuperable.
Unos pantallazos nuevos, para abrir boca:
54756
54757
Por cierto, el sonido 100% digital sampleado y comprimido, ¡suena como los ángeles!
SplinterGU
11/12/2021, 08:42
No sólo son un memcpy hardware; los canales DMA acceden al cartucho y RAM, cuando el bus está libre. Cuando la CPU no está utilizando el bus de memoria. Eso es así con todos los DMAs, desde MegaDrive, microcontroladores, hasta los PCs que tenéis delante.
Recordad que en estas máquinas, la RAM era aún mucho más rápida que la CPU y los adaptadores de vídeo y sonido; y por eso metieron DMAs, blitter, sprites hardware todo cuanto pudieron. Para aprovechar el tiempo que estaba libre la RAM. Esta manera de diseñar computadores encuentra su límite técnico en el Falcon de Atari.
En MegaDrive la RAM pese a ser más lenta que en un ST, tiene mayor ancho de banda; al ser toda RAM estática y no necesitar refresco (se ahorraron la circuitería y la lógica para refrescar, que no es nada sencillo, a costa de una RAM más cara). Quizá por eso acabaron dejando la VRAM en sólo 64 KB, porque al ser SRAM es más cara. Por cierto, que el VDP funciona a 13 MHz, y cuando construye un fotograma, pinta los sprites línea a línea... la memoria donde el VDP construye la información de la línea (es interna al VDP, hay espacio para dos líneas, la que pintas, y la que sale por el vídeo) para que a continuación la pinte en pantalla el DAC de salida de vídeo, es de 256 bits a 8 MHz (éste dato si me ha parecido sorprendente).
Las capacidades DMA se encuentran sólo en el adaptador de vídeo, el VDP; tiene una caché de instrucciones de 256 bytes. Puedes organizartelo para que sea todo instrucciones relativas a transferencia DMA, para que se encadenen ellas solitas; siendo el resultado final más potente y complejo que un sólo memcpy; es como encadenar múltiples memcpy. Como recomendación, no exceder 200 tiles por frame.
Los gráficos, cuando están comprimidos; deben ser transferidos del cartucho a la RAM del 68000 (éste trabajo lo hace el 68000), el 68000 lo descomprime tile a tile en su propia RAM, y escribe la órdenes DMA en la caché del VDP; el VDP empieza a copiar a la VRAM mientras el 68000 aún sigue descomprimiendo tiles.
Por supuesto, no es muy recomendable utilizar compresión ni para animaciones ni para el mapeado; salvo que el mapeado avance muy lentamente; o vayas a hacer grandes cambios de tiles en la VRAM y se vayan a quedar ahí bastante tiempo.
La compresión en el sonido es bastante útil ;)
Gracias a esto último, la Misión 1 del port de Metal Slug de Atari STE, cabe en tan sólo 1 MB en su versión MegaDrive.
Y a lo que comentaba Chipan; hay unos marrones muy gordos respecto al adaptador de vídeo de MegaDrive; sobretodo cuando utilizas sprites estáticos (todos los frames cargados en la VRAM) y a cómo gestionas los procesos / sprites que se van viendo en pantalla...
por poner un ejemplo: como un sprite alguna vez sólo dure 1 fotograma... ya puedes rezar, porque hacen falta varias pasadas de los datos de un sprite a través de la lógica del VDP en frames sucesivos; en este ejemplo se producirían bugs gráficos y atascos del bus de memoria (con retardo, para confundir más si cabe) provocados por un malfunciomiento del VDP y es irrecuperable.
Unos pantallazos nuevos, para abrir boca:
54756
54757
Por cierto, el sonido 100% digital sampleado y comprimido, ¡suena como los ángeles!
esos son capturas de MD? lo del sonido 100% digital que suena como angeles es de MD? si es asi, me alegra saber que has quedado contento con eso! :)
A eso me refería: cuando vimos los chips de DMA en clase, se los definió como un pequeño controlador programable, independiente de la CPU, que se encarga sólo de transmitir información por el bus de datos, de un elemento a otro (RAM, puerto serie, puerto paralelo, USB...). Se le pasaba una dirección inicial de origen, una de destino, y la cantidad de datos, y él ya hacía el trabajo de transmitir y sincronizarse.
Pero claro, el procesador más complejo que vimos era el 68000. Lo mismo, la DMA que vimos era la más básica de todas ¿Por qué la DMA no puede tener más espacio de memoria y almacenar un pequeño código de compresión de datos? O de descompresión, encriptación, conversión Little-Big endian... Cosas sencillas.
Tuve un laboratorio en que un DSP, con apenas 30 líneas en ensamblador, al reproducir un sonido, le programábamos eco, o un ecualizador, o un reductor de ruido ¡hasta la decodificación del sonido del Canal+! Todo en tiempo real.
¿Me dices que con 256B no se puede hacer un descompresor LRE, que a la vez que lee del cartucho, expande la información en la VRAM? Que es lo que hacía el chip del Street Fighter 2 que mencionaba antes, que si no recuerdo mal, iba en el cartucho de SNES.
Pero claro, el procesador más complejo que vimos era el 68000. Lo mismo, la DMA que vimos era la más básica de todas ¿Por qué la DMA no puede tener más espacio de memoria y almacenar un pequeño código de compresión de datos? O de descompresión, encriptación, conversión Little-Big endian... Cosas sencillas.
Importa poco la CPU porque el DMA se implementa con circuiteria externa, con tener un registro para guardar el dato que leen de memoria es suficiente, aunque con memorias mas modernas seria mas eficiente leer trozos un poco mas grandes y después escribirlos, aunque en ese caso también tendrás CPU mas moderna y haciendo un simple memcpy tendras "el mismo" rendimiento, dudo que los ordenadores modernos tengas canales de DMA.
Y no no pueden descomprimir ni encriptar porque en ese caso seria un circulito de descompresión o de encriptacion y no un DMA :P
Importa poco la CPU porque el DMA se implementa con circuiteria externa, con tener un registro para guardar el dato que leen de memoria es suficiente, aunque con memorias mas modernas seria mas eficiente leer trozos un poco mas grandes y después escribirlos, aunque en ese caso también tendrás CPU mas moderna y haciendo un simple memcpy tendras "el mismo" rendimiento, dudo que los ordenadores modernos tengas canales de DMA.
Y no no pueden descomprimir ni encriptar porque en ese caso seria un circulito de descompresión o de encriptacion y no un DMA :P
Al parecer me he explicado mal. No estoy diciendo que el 68000 tenga HW de DMA, sino que es un ejemplo para que tengas referencia de cuándo aprendimos todo sobre ordenadores, y que sepas que mis datos andan desfasadísimos.
Los DMA siempre han ido aparte, es un CI distinto de la CPU, y, cuando yo lo estudié, iban soldados a la placa base y eran los responsables de dirigir el tráfico del bus de datos, tanto el north bridge como el south bridge (que nunca recuerdo qué comunica cada puente ¿CPU-RAM y CPU-periféricos?) y dejan libre a CPU, GPU y otros microcontroladores mientras se copian los datos.
Pero como digo, un microcontrolador puede tener cierta capacidad de cómputo, y en el ejemplo que decía del DSP, con un buffer de apenas unos Ks (no recuerdo cuántos, pero suficientes para almacenar valores discretos de una onda sonora durante 1 o 2 segundos), podías hacer virguerías. ¿Por qué no meterle 2KB a un chip DMA, que vaya almacenando datos comprimidos y los mande sin comprimir? El algoritmo SLE que comentaban más arriba, por ejemplo, se puede implementar en ASM en apenas unos pocos bytes, con una ALU con las operaciones lógicas, aritméticas y binarias básicas.
Los relojes-calculadora llevan un microcontrolador más complejo que lo que estoy hablando, por eso no me extrañaría que una MD tenga un chip DMA más complejo que sólo un "memcpy".
masteries
13/12/2021, 20:00
dudo que los ordenadores modernos tengas canales de DMA.
ufff!! ¡Menos mal que no soy un fan boy! Como los Amigu**** de los coj****
Están por todas partes; el adaptador de audio sigue enviando los samples mezclados al DAC de esa forma... las CPUs tienen unos cuantos gobernados por la circuitería de la caché...
se han vuelto muy complejos y sofisticados.
El adaptador de vídeo hace así sus transacciones de datos entre la RAM del sistema y el puerto PCI-Express / o AGP (algo más viejuno), y el puerto serie, y los USB, y las controladoras de disco duro...
El DMA es el amo omnipresente; sin ellos tus discos duros se comerían la CPU.
Otra cosa es que ya no sea común programarlos, porque su manejo esté integrado en los drivers; pero si escribes código para el kernel, puedes usarlos.
De hecho no hace mucho que tuve que reescribir uno, para manejar un puerto serie a través de USB a 5000 Hz. Por culpa del maldito Windows 10 y sus contantes cambios de kernel... :(
Eso o lo programas para el kernel (de Windows, o Linux, o el que sea) o difícil lo vas a tener para alcanzar ese número de transacciones por segundo,
y es una gestión de DMAs.
Si, pero me referia a los DMA como en los ordenadores antiguos, como un circuito especifico y separado para copiar datos, supongo que en una GPU cuando le mandas los datos gordos como los vertices, texturas o cosas así ya llevaran algo para copiar eso a toda pastilla.
Por lo que ha dicho Masteries, creo entender que no sólo es que haya uno, sino que hay varios repartidos por toda la placa, especializados según la tarea.
masteries ¿acabas de decir que los DMA se pueden programar? ¿En qué sentido, qué se le puede decir que haga? ¿Se pueden tratar los datos o es sólo la configuración del protocolo de envío de datos?
masteries
14/12/2021, 13:32
Por lo que ha dicho Masteries, creo entender que no sólo es que haya uno, sino que hay varios repartidos por toda la placa, especializados según la tarea.
@masteries (https://www.gp32spain.com/foros/member.php?u=28729) ¿acabas de decir que los DMA se pueden programar? ¿En qué sentido, qué se le puede decir que haga? ¿Se pueden tratar los datos o es sólo la configuración del protocolo de envío de datos?
Si, hay bastantes repartidos por la placa; integrados en los chipset... y en la propia CPU
Los del USB se pueden programar a voluntad; de hecho cada categoría de dispositivo: Mass Storage, Virtua Com Port (es un subtipo de - Class Communication Device), es accesible directamente desde el chipset saltándote el driver de la capa de mayor abstracción.
Está estandarizado y hay una API publicada, soportada por las BIOS de vuestros ordenadores PC. Así es como podéis arrancar con un pincho USB.
Programando para el kernel, puedes acceder a un dispositivo de esta forma y utilizarlo a voluntad; también colgarás el ordenador un porrón de veces hasta que lo consigas... xD
se muere como en los viejos tiempos, se queda congelado, ni pantallazo azul ni nada... porque el S.O. no te está supervisando. Es como programar un driver, pero menos complejo , porque tu dispositivo externo lo creas basándote en una clase de dispositivo que ya está directamente soportado por el chipset y la bios.
Consultas la lista de dispositivos; asignas tu funciones de IRQ y DMA y a trabajar. Para enviar y recibir datos desde Windows, tienes disponible un buffer, pipes... yo utilizo el buffer, cuando Windows retoma su ejecución (en Windows XP es cada 1 ms), en los más modernos no lo tienen claro ni ellos; pues consultas el flag del buffer, te indica que tiene datos, los lees... los pintas en una gráfica, mandas a dormir el programa / proceso... vuelve a ejecutarse el kernel para que vuelves a ordenar transacciones de datos o consultarlas...
Las IRQ y DMAs, sé que las DMAs del USB las realiza completamente el chipset, las IRQs del USB... ya no lo tengo tan claro, posiblemente el chipset se lo pida a la CPU; hoy día las CPUs son tan rápidas que no te queda claro xD
Este tipo de programas dan problemas si el ordenador está muy plataformado, antes habría que dar permisos al software.
Pero vamos, es lo mismo que hacen DirectX o Vulkan; sólo que a un nivel no tan Pro ni sofisticado
Esta cosas las hacen quienes están obligados a hacer software en Tiempo-Real para el PC,
y el proyecto no se permite el lujo de utilizar un S.O. como VxWorks o QNX - También porque así el mismo equipo te sirve para adquirir / procesar y hacer el resto de cosas, porque en esos citados S.O. poquito software hay.
Si, hay bastantes repartidos por la placa; integrados en los chipset... y en la propia CPU
No lo sabia, aunque en parte es normal, mira apple con los M1, que en el mismo integrado te mete de todo, hasta para cifrar los datos. A fin de cuentas, con el nivel de integracion que hay te cabe de todo.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.