Eteream escribió:He hecho una modificación del Gens para que se remarquen los sprites. ¿Alguien sabe de un programa para capturar video desde pantalla y/o editarlo?
Pues el virtualdub! dónde tendria yo mi cabecita...
video de prueba:
http://www.youtube.com/watch?v=U3Pqyr4UMDU----------------------------------------------------------------------------------------------------------------------------
magno escribió: No puede venir una interrupción porque los DMA sólo se ejecutan durante el NMI = Non Maskarable Interrupt
NMI es una propiedad de una interrupción, no un nombre de una interrupción. Significa que dicha interrupción no puede desactivase, el software debe responder a ella. Confundes NMI con vblank.
Los DMA se pueden lanzar siempre que el bus este libre o ready para la dma, no necesariamente durante una vblank.
Como ya te dije la vram de la snes sólo esta libre en vblank o hblank, así que si quieres usarla, si que tienes que esperar a un Xblank, pero si deseas usar otra memoria, NO.
magno escribió:así que mientras esta interrupción está activa, se deshabilita la IRQ (que es la otra señal de activación)
Otra vez lo mismo, IRQ es el anacronismo de Interrup ReQuest, o interrupción. No el nombre de una interrupción en concreto.
Lo que realmente sucede es que los DMA paralizan por completo la cpu, entonces no pueden haber interrupciones (no se detectan). Lo he mirado y la snes esta diseñada así, extraño pero cierto.
magno escribió:Durante el H-DMA (DMA horizontal que ocurre en los primeros 18 ciclos maestros tras el sincronismo horizontal) no puede saltar la NMI porque está en una línea de video activo, así que tampoco hay interrupción.
Cierto, es obvio que durante un hblank no se puede producir un hblank -> la moneda cae o de una de las dos caras o de canto, pero nunca de las dos caras a la vez, obviedad absoluta y absurda.
¿Sólo dura 18 ciclos de reloj el hblank? ¿es eso lo que quieres decir?
A parte de las interrupciones generadas por los hblank y vblank, hay otras interrupciones; por lo que tu afirmación puede ser (según el caso) falsa.
magno escribió:Si la IRQ salta en este momento, lo mismo, queda inhibida hasta que la CPU salga del estado STALL.
Exacto, la cpu queda paralizada mientras hayan DMA's en curso.
Como te dije, en este párrafo veo un lío de conceptos bastante grande. Deberías leer bibliografía sobre fundamentos de computación.
magno escribió:Pues sí, sí es verdad lo que he dicho, puedes consultarlo en cualquier documentación actualizada de la SNES. La CPU no puede trabajar con la memoria porque INSISTO que el bus A se usa para la DMA: las transferencias son desde el bus A (que conecta RAM con CPU) y el bus B (que conecta la VRAM con CPU), así que al estar ocupados, no se puede hacer nada de nada. Así que lo de la preparación de los sprites, que podría ser una opción, no ocurre.
Esto es un despropósito. A ver... si los chips gráficos tiene memoria PROPIA es por una razón: NO ACCEDER AL BUS DEL SISTEMA. La memoria de video tiene dos "puertas", una que comunica con el bus para que la cpu acceda y otra que comunica directamente con el chip grafico. El chip grafico no necesita ni DMA ni nada para funcionar, sólo la VRAM (y los registros i/o, que no son ningún problema). En el caso de la SNES sólo una puerta debe estar abierta para que todo vaya bien. Si lo que dices estuviera bien significaría que, a la hora de la verdad, la SNES va a unos pocos Khz, vamos que la GB seria un monstruo de cpu en comparación.
magno escribió:En absoluto, eso es totalmente imposible. Si "apagaras" el chip gráfico, la TV perdería el sincronismo de línea y la imagen temblaría. Lo que pasa es que la memoria de video se puede escribir SOLO mientras no se está leyendo, y eso ocurre cuando el chip gráfico está haciendo el barrido vertical. La VRAM no es de doble puerto: si lees, no escribes, y viceversa.
Desactivar el chip gráfico, código:
LDA 0x0010 ; Carga en el registro A el valor inmediato
STA (0x2100) ; Guarda el valor del registro A en la dirección de memoria*
* es posible que la sintaxis no sea la correcta, no conozco este asm.
http://en.wikibooks.org/wiki/Super_NES_ ... _Registers¿Problemas de sincronía con la TV? Ninguno ya que el chip grafico no es el que genera la señal de TV, el chip gráfico sólo genera una señal digital. Existe otro chip llamado comúnmente DAC (Digital to Analog Converter) que es el que genera la señal de TV (o analógica que corresponda) y este nunca para de enviar la señal correcta. Supongo que el chip grafico pone sus salidas a 0 y el DAC las interpreta como negro.
Por ejemplo en N64 el problema que hay con la salida de RGB es que Nintendo, en su infinita sabiduría, a partir de un momento, quitó las salidas correspondientes al scart/euroconector del DAC, supongo que para ahorrar costes (3 patillas!). Pero como el chip grafico SI genera el RGB en digital, pues tengo una solución en camino… algún día el mundo no será borroso.
magno escribió:El doble buffer es una técnica que se usa en todas las tarjetas gráficas, así que alguna mejora traerá. Si se pudiera hacer como decía yo antes, en la hipótesis que dije con otra arquitectura diferente, se gana EL DOBLE DE TIEMPO, ya que mientras se transfiere de RAM a VRAM se hace simultáneamente de ROM a RAM.
Leyendo esto se me cayó el mundo encima. No entiendo como puedes discutir conceptos avanzados si no entiendes lo más básico.
!!!!!!!! LAS CONSOLAS 2D NO TENIAN FRAME BUFFER !!!!!!!!
!!!!!!!! NO PINTA NADA (literalmente) UN DOBLE BUFFER !!!!!!!!!!!!
!!¿ De dónde sacas que se gana el doble de tiempo???? No tiene nada que ver con eso, se usa un doble buffer para no tener problemas de sincronización. ¿Sabes lo que se ve por televisión cuando sacan un ordenador de fondo, todas esas imágenes desincronizadas? Se usa el doble buffer para evitar eso. Si te paras a pensar en todo el proceso no se gana NADA de tiempo, aunque en un principio pueda parecer que si.
Volviendo a la snes (u otras consolas 2d), como he dicho no tiene frame buffer, no tiene un área de memoria que representa lo que se ve en pantalla como si fuera un "bitmap", sino que cada pixel se calcula de forma independiente por el chip gráfico en el momento necesario, y lo por tanto, siempre sincronizado, y se pasa a directamente al DAC, de este modo se pueden hacer efectos gráficos muy logrados sin mover casi bytes.
¿No sabias que la memoria RAM era (!y lo continua siendo!) muy muy muy extraordinariamente cara?
¿Por que crees que los PCs nunca tuvieron un nivel 2D comparable a las consolas? (Hasta la llegada de las aceleradoras, obviamente).
magno escribió:En cuanto a las afirmaciones sobre la CPU son totalmente erróneas... en absoluto es una arquitectura de 8 bits vitaminada a nada... es una arquitectura completa de 16 bits pero compatible hacia atrás. Te recuerdo que ese micro se usa en el Apple II GS. Y su conjunto de instrucciones es exactamente como cualquiera de su época (¡¡¡¡1986!!!!!) un RISC como los de toda la vida.
Hay que informarse un poquillo más antes de afirmar tantas cosas ligeramente, ¿eh?
Bueno esto es fanatismo y no puedo hacer mucho contra ello. Me dices que el el Apple II GS lo usaba, pero ese ordenador es de unos cuantos años atrás (6!!). Me dices que es una cpu completa de 16bits pero admites que los buses son de 8bits. Su conjunto de instrucciones parece más a un z80 que no a un 68000, por ejemplo la idea de esta cpu es operar con registros especializados (1 acumulador, 2 índices, 2 registros de swap y nada más), esta es la idea reinante en la era de los 8bits, pero ya antes de 1990, la idea cambió a trabajar con registros polivalentes con las CPUs de 16 y 32 bits. La familia de los 6502 son todas CPUs de de 8bits, excepto el último modelo, que aunque mantenía el diseño interno, en parte se pasó a 16bits, casualmente es la cpu de la snes; más información en la wikipedia.
Bueno, pues, no te enfades y lee literatura sobre arquitectura de computadores, y no tanto "info sobre consolas" a medio explicar; yo lo hago habitualmente.
----------------------------------------------------------------------------------------------------------------------------
Eteream escribió:Ketk escribió:Eteream escribió:El nombre "modo 7" viene pq en snes hay 7 modos. En este modo sólo puede haber una sola capa (la palabra fondo, como veis, es totalmente desacertada) y, por supuesto, sprites. No os dejéis engañar por los trucos de los programadores, que se las buscaban todas!
http://en.wikipedia.org/wiki/Super_Nint ... stem#Video
Vamos.. lo dicho.. que si quieres un enemigo gigante sólo vas a tener uno y sin fondo.. a menos que recurras a lo tradicional y lo hagas a base de sprites
Exacto. La snes soporta unos 120 sprites de hasta 64x64 (o algo así). Con eso se puede hacer el enemigo gigante que quieras. También puedes aprovechar el modo 7 y hacerlo con una capa, y así ganas rotaciones y scalado por hardware, que como se sabe la snes no va sobrada de cpu. Con esta última idea el problema es que si pones más cosas en la capa, esas cosas rotaran del mismo modo que el enemigo. Así que si pones un fondo de un único color no se nota que también va rotando; con sprites extras, generas algo de adornos (como fondo) para que no quede demasiado sobrio.
Todo depende de lo que quieras, exactamente, hacer.
Bueno, despues de la sesión maratoniana que me he pegado de hard de snes, he "descubierto" otra maner de usar el modo 7 con layers (eso que algunos llaman fondos). Para entenderlo es ABSOLUTAMENTE necesario entender que la snes no tiene frame buffer, como he dicho antes en este mensaje.
Consiste en cambiar de modo en medio de un pintado, concretamente en un hblank. Entonces parte de la pantalla se pinta según las reglas del modo 7 y otra parte en otro modo. Permitiendo tener más de un layer en pantalla, pero separados, en distintas lineas.
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
![[snif]](/images/smilies/nuevos/triste_ani1.gif "llorando")
)
