User Tag List

Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo
Resultados 31 al 45 de 47

Tema: Dándole caña a MegaDrive - Necesidad de suite gráfica con opciones de Dithering

  1. #31

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,705
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,268
    Agradecer Thanks Received 
    1,335
    Thanked in
    Agradecido 915 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    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

    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  2. #32

    Fecha de ingreso
    Sep 2005
    Mensajes
    13,641
    Mencionado
    221 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    429
    Agradecer Thanks Received 
    1,145
    Thanked in
    Agradecido 817 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por chipan Ver mensaje
    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.

    Cita Iniciado por swapd0 Ver mensaje
    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.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  3. #33

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,705
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,268
    Agradecer Thanks Received 
    1,335
    Thanked in
    Agradecido 915 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  4. #34

    Fecha de ingreso
    Sep 2005
    Mensajes
    13,641
    Mencionado
    221 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    429
    Agradecer Thanks Received 
    1,145
    Thanked in
    Agradecido 817 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  5. #35

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,705
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,268
    Agradecer Thanks Received 
    1,335
    Thanked in
    Agradecido 915 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  6. #36

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,781
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    918
    Agradecer Thanks Received 
    560
    Thanked in
    Agradecido 342 veces en [ARG:2 UNDEFINED] posts
    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...
    ...

  7. #37

    Fecha de ingreso
    Dec 2004
    Mensajes
    28,314
    Mencionado
    194 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    155
    Agradecer Thanks Received 
    2,178
    Thanked in
    Agradecido 1,381 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    11
    Cita Iniciado por Iced Ver mensaje
    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.
    Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia la latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.

  8. #38

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,197
    Mencionado
    102 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    254
    Agradecer Thanks Received 
    877
    Thanked in
    Agradecido 430 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    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:

    Nombre:  MD_wip1.jpg
Visitas: 1783
Tamaño: 83.2 KB

    Nombre:  MD_wip2.jpg
Visitas: 1985
Tamaño: 77.5 KB


    Por cierto, el sonido 100% digital sampleado y comprimido, ¡suena como los ángeles!
    Última edición por masteries; 11/12/2021 a las 00:54

  9. Los siguientes 3 usuarios agradecen a masteries este post:

    fbustamante (11/12/2021), Karkayu (11/12/2021), SplinterGU (11/12/2021)

  10. #39

    Fecha de ingreso
    Jul 2009
    Mensajes
    8,781
    Mencionado
    64 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    918
    Agradecer Thanks Received 
    560
    Thanked in
    Agradecido 342 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por masteries Ver mensaje
    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:

    Nombre:  MD_wip1.jpg
Visitas: 1783
Tamaño: 83.2 KB

    Nombre:  MD_wip2.jpg
Visitas: 1985
Tamaño: 77.5 KB


    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!
    ...

  11. El siguiente usuario agradece a SplinterGU este mensaje:

    fbustamante (11/12/2021)

  12. #40

    Fecha de ingreso
    Sep 2005
    Mensajes
    13,641
    Mencionado
    221 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    429
    Agradecer Thanks Received 
    1,145
    Thanked in
    Agradecido 817 veces en [ARG:2 UNDEFINED] posts
    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.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  13. #41

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,705
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,268
    Agradecer Thanks Received 
    1,335
    Thanked in
    Agradecido 915 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    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
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  14. #42

    Fecha de ingreso
    Sep 2005
    Mensajes
    13,641
    Mencionado
    221 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    429
    Agradecer Thanks Received 
    1,145
    Thanked in
    Agradecido 817 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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".
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  15. #43

    Fecha de ingreso
    Oct 2007
    Ubicación
    Madrid
    Mensajes
    3,197
    Mencionado
    102 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    254
    Agradecer Thanks Received 
    877
    Thanked in
    Agradecido 430 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje

    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.

  16. #44

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    6,705
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,268
    Agradecer Thanks Received 
    1,335
    Thanked in
    Agradecido 915 veces en [ARG:2 UNDEFINED] posts
    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.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.

  17. #45

    Fecha de ingreso
    Sep 2005
    Mensajes
    13,641
    Mencionado
    221 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    429
    Agradecer Thanks Received 
    1,145
    Thanked in
    Agradecido 817 veces en [ARG:2 UNDEFINED] posts
    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?
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

Página 3 de 4 PrimerPrimer 1234 ÚltimoÚltimo

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •