Señor Ventura escribió:Creo que bastaría con que no causase los estragos que causa durante la pantalla activa, aunque sea solo por el tiempo de proceso que podría estar usándose para tareas lógicas, ir adelantándo trabajo para la ejecución de una rutina de físicas, o mismamente descomprimir gráficos... lo que sea.
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.
Señor Ventura escribió:En realidad hay algo que lleva un tiempo martilleándome, y no consigo encontrar ningún fundamento para razonar su implicación... ¿que hubiera pasado si el bus de datos hubiera sido de 16 bits? (aparte de que se hubiera necesitado otra memoria VRAM para adaptarse a ese incremento de datos simultáneo).
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)
Señor Ventura escribió:(editado: corrijo lo que dije antes, estoy leyendo que el bus de datos sin utilizar del PPU2 no era de 8 bits, sino de 24 bits. Monstruoso, simplemente no me quiero imaginar para que tenían pensado usar esa memoria.).
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.
Señor Ventura escribió:¿En teoría un descompresor de gráficos como el SDD1 podría aumentar virtualmente el ancho de banda del bus de datos?, o no hay forma de saltarse el DMA...
El MSU-1 parece que se lo salta, vamos...
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".
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).