magno escribió:Realmente durante el tiempo activo de la pantalla no causa ningún estrago porque no se puede usar el DMA para enviar cosas a VRAM; la memoria de video VRAM hay que verla como una memoria con 2 puertos: por uno el micro principal escribe por DMA (normalmente, aunque tb lo puede hacer byte a byte) y por el otro puerto, el micro de la PPU lee para formar los píxeles que van a pantalla.
Es por eso que durante la parte activa de la pantalla no se puede escribir esa memoria VRAM porque estarías modificando/corrompiendo los datos que la PPU está leyendo para formar el frame actual en la TV.
En realidad me refería al hecho de tener la cpu parada mientras el DMA está activo... pero ahora que lo explicas entiendo a que se debe.
Lo cierto es que imaginaba que el DMA estaría fuera del sistema de vídeo, por eso no me explicaba que clase de diseño podría causar que la cpu se parase, sin que se tratase de otro elemento que se comportase como tal (como otra cpu, pero con otras funciones), porque de otra manera no podría ser.
Siempre me pareció una pega que la snes no pudiese transferir datos durante la pantalla activa, pero empiezo a entender que su ventaja es que es muy autónomo.
En megadrive por ejemplo se puede escribir en la VRAM durante la pantalla activa, mientras que su VDP lee para sacar los scanlines en la pantalla... pero debe necesitar de algún tipo de gestión(recursos) para no tocar lo que no debe. Eso en snes no pasa.
P.D: Si digo alguna burrada tengo excusa, que debería estar durmiendo

magno escribió:Si el bus de datos hubiera sido de 16 bits, habría que haber cambiado de micro, ya que el 65C816 no puede gestionarlo con la arquitectura que tiene.
Pero suponiendo que hubiera sido así, desde el punto de vista del micro poco hubiera cambiado, quizá hubiéramos ganado 1 ciclo por instucción cuando el acumulador está en modo 16 bits. Pero en las instrucciones de acumulador de 8 no se hubiera notado porque el micro gasta 1 ciclo en decodificar la instrucción.
Desde el punto de vista de la PPU, pues se habría duplicado el ancho de banda efectivo entre CPU (bus A) y VRAM (bus B)
En realidad pregunto específicamente por el bus de datos por el que puedes escribir directamente en la VRAM desde la ROM, que es justo por donde viajan las tiles de sprites y planos.
¿Es a esto a lo que te refieres cuando apuntas que la cpu no podría gestionarlo si fuese de 16 bits?... es que, efectivamente, podrían viajar casi el doble de datos, y eso es mucha tela.
magno escribió:Esto no lo conocía... ¿24 bits? ¿Dónde has visto eso? Lo que yo decía antes de ampliar la VRAM es porque en la arquitectura actual el bus de direcciones para la VRAM es de 15 bits (registros $2115/16), es decir, solo se direcciona $0000 hasta $7FFF, pero ese bit se podría usar para direccionar entre $8000 y $FFFF, y creo que internamente ese bit no está capado, simplemente bastaría con "añadir" otro chip de DRAM de 64Kbit. Lo que pasa es que los 64 Kbits que se usan ahora mismo están dentro de uno de los dos chips que forman el sub-sistema de video y no es tan fácil como soldar un chip más.
Pues lo he leído de aquí (en el último párrafo del primer post):
http://board.zsnes.com/phpBB3/viewtopic.php?f=6&t=11776Me ha extrañado, porque no tiene ningún sentido, pero lo ha afirmado tan alegremente que vete tu a saber si realmente habla con conocimiento...
P.D: Te refieres a otro chip de 64KB, no 8KB, ¿puede ser?.
magno escribió:No, el S-DD1 lo que hace es "esnifar" las transferencias DMA entre la ROM y la memoria RAM del sistema o la VRAM de video y cuando el DMA arranca, en vez de devolver los bytes leídos de ROM, devuelve en cada ciclo de lectura del DMA un byte descomprimido. Es como que se mete enmedio del DMA para sustituir bytes "normales" por bytes "descomprimidos al vuelo".
Entendido, el sistema no adquiere ninguna ventaja adicional.
magno escribió:El MSU-1 no se lo salta, de ahí la limitación del video que puede representar. El MSU-1 reproduce video a 15fps y 256x208 (o 256x224, no recuerdo bien) con 16 colores porque ésa es la máxima velocidad de transferencia de datos del DMA. La forma de "saltarse" el DMA para escribir en VRAM es hacerlo byte a byte con el micro, lo cual es como unas 30 veces más lento (teniendo en cuenta el bucle que habría que hacer para escribir).
Saltarse el DMA es mas lento porque entonces lo que hace es acumular "datos" durante mas tiempo para que cada frame tenga mas información (mas profundidad de color), ¿no?... pero claro, adios muy buenas a la fluidez de la reproducción.
P.D: Estoy viendo que el MSU1 reproduce vídeos a 256 colores, o eso dicen:
"The MSU-1 enables the Super Famicom to support up to 4GB file size, full motion video (240×144, 256 color, 30fps) and uncompressed 44.1KHz 16-bit stereo PCM".https://cdromrom.wordpress.com/2014/11/ ... nd-sfc-cd/Debe haber algún modo, porque si el MSU1 transfiere tiles de planos (no sprites) a 9MB/s, de algún truquito se debe servir para ofrecer vídeos con esas especificaciones.
editado: Aquí un poco de información del propio byuu
http://forums.nesdev.com/viewtopic.php?p=146179#p146179Con esto consigues 8bpp (256 colores), imagino que a 15fps... ¿o tal vez a 30? (son las 4 de la mañana, y ya no doy para mas xD).
magno escribió:kusfo79 escribió:Bueno, eso es medio verdad. La CPU de la SNES no puede realizar multiplicación nativamente (como casi todos los micros de la época), pero eso solo es importante en ciertos cálculos. Aparte, la APU de la SNES si que contiene instrucciones nativas de multiplicación y división.
Y eso también es verdad a medias
![carcajada [carcajad]](/images/smilies/nuevos/risa_ani2.gif)
La multiplicación en la SNES se puede hacer de 16 bits a través de un core que estaba dentro de la PPU (no de la APU), o de 24 bits a través de la multiplicación de matrices para el modo 7 (si estás usando cualquiera de los otros 6 modos).
La APU hace multiplicaciones para su procesado de audio, pero no son útiles para el micro, puesto que habría que descargar un código especial a la APU para que las hiciera y esto sería realmente lento.
Ya decía yo que con todo el "raw power" del ppu era un desperdicio no usarlo a tope.
Es decir, ya en otra ocasión me contaste que podía realizar tareas de multiplicación... pero operaciones de 24 bits me parece una salvajada. 8 ciclos de reloj para enviar la instrucción, y ale... caña...
![Ala! [Alaa!]](/images/smilies/nuevos/sorprendido_ani2.gif)
Tengo una duda, ¿puedes usar ese core para hacer operaciones de multiplicación de 16 bits mientras estás en modo 7?.