Me puse a analizar el codigo del super mario world original. Despues de analizarlo un buen rato descubri que en teoria no necesitabas ningun parche especial para hacer sprites dinamicos.

Probe en un rom el codigo haciendo los cambios que pense que debia hacer.

Al final funciono, sin ningun parche especial pude hacer un sprite dinamico y funciono en todos los emuladores incluyendo el bsnes.

Ademas como detalle adicional descubri que es falso que maximo en un frame puedes transferir 2 kb de informacion.

Puse 4 sprites dinamicos de 64X64 y los 4 funcionaron perfecto, eso son 8 kb de informacion en un solo frame.

enserio? quien rayos invento todos esos mitos, han retrasado mucho el hacking por eso. La razon por la que funciona el dsx es solamente por que en ese lugar cumple los requisitos para hacer las cosas, pero esos requisitos los puedes poner en cualquier zona incluyendo blocks, sprites, level asm.

Hare mas pruebas para asegurarme que todo este perfecto. Con este descubrimiento no solo cambiaria mucho mi parche dinamico sino que tambien mucho lo que es hacer sprites. De hecho dije esto en el irc y les dije "pude hacer una rutina dinamica en un level asm y funciono, solamente hice esto" y me dijeron pero eso no deberia funcionar en un sprite, luego lo probe en un sprite y les dije "lo probe en un sprite y funciono hasta en el bsnes" y quedaron como WTF. luego lui hizo lo mismo para cambiar paletas y le funciono usando lo qu yo dije y todos se quedaron callados xD.

El LevelASM esta en un F-Blank (Blank forzado), por lo tanto, hacer una escritura a registros de la snes en ese lugar es totalmente seguro, los blocks y sprites no estoy seguro si estan en algun blank (a menos de que alguna manera forces un blank para poner el codigo (aka poner el bit 7 de 2100? activo)), pero igual no se.

Lo de el DMA y lso 8kb me daba la impresion de que si estaba mal que solo pudiera transferir 2kb de data, porque el DMA esta en un bus que trabaja bastante rapido (transfiere 1 byte en cada 8 ciclos (creo, quizas menos porque son demasiados ciclos y con eso termina siendo mas eficiente un LDA STA lol). Ademas, tambien hay que tomar en cuenta los demas juegos que se nota a simple vista que usan DMA hasta para hacer cosas que un LDA STA harian (<- es broma). DKC se nota que utiliza DMA PARA TODO, por eso es que se me hizo bastante raro que pudiera controlar tantos sprites dinamicos y todos de buen tamaño y con 100% de probabilidad de exceder la capacidad "fantasma" de ese bus del DMA.

Ademas, creo que el SMW usa DMA para actualizar los tiles de map16 que seran dibujados en camara lol, el SMW basicamente se puede decir que esta mal programado en todos los aspectos, pero esa mala programacion es lo que lo ha hecho bastante hackeable en todos los aspectos.

Los sprites no son en un Blanc forzado, te explicó la vram es similar a la RAM normal, pero tiene una protección de escritura, esta protección se saca seteando una interrupción con sei, esto es común en otras arquitecturas, de hecho al usar sei fuerzas una interrupción, normalmente el snes espera una interrupción natural que hace el mismo snes usando el comando wai, una ves está la interrupción empieza a cargar el sonido, gráficos y renderear la pantalla. Al usar sei engañas a la snes para que te permita escribir en la vram o cgram.
Sobre lo del dma para cargar los tiles que muestra en pantalla es falso. El smw hace un chequeo para ver si está al inicio de un nivel o durante el nivel . Sólo carga tiles a los layers al inicio del nivel , sólo usa el registro de scrolling para mover la cámara de hecho si hiciera eso que dices, el gema de scrolling no serviría de nada.