gasega68k escribió:Lo que pasa en el snes es que cuando se intenta enviar datos a la vram durante el periodo activo la imagen se destruye(el snes explota
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
... es broma), lo que creo es que solo se puede escribir en un momento exacto (durante el hblank) y eso es lo que hace el hdma.
Al parecer la cosa funciona así:
Durante el VBLANK tienes 8 canales DMA que son usados para transferir datos de la ROM a la VRAM, o a la RAM del sistema, o a la RAM del SPC700. Tambien puede ser empleado para comunicar a la RAM del sistema con la VRAM, ya que las tablas para las transformaciones del modo 7 se almacenan en la RAM del sistema, y no en la memoria de vídeo.
En este proceso, solo se puede usar un canal DMA simultáneamente, así que durante el VBLANK, por motivos obvios, no se puede emplear el HDMA.
Luego hay otro impedimento, tras el VBLANK hay un período de 40 ciclos de reloj en que los datos movidos por el DMA son actualizados por el sistema, y en ese tiempo, directamente todos los buses DMA y HDMA son desactivados (no hay ningún transporte de datos ni de la ROM a las memorias internas de la snes, ni hay ningún transporte de datos entre las memorias internas de la snes).
El resto del tiempo que no es lo comentado, es el denominado período activo, y en el si está activo el HDMA. Por lo que, muy en contra de lo que se decía de snes, si hay un bus funcionando en todo momento.
Lo malo es lo que tu dices, que no solo el espacio de acceso que permite es irrisorio, es que además intentar enviar cualquier sprite a la memoria de vídeo da como resultado la corrupción de datos.
¿El punto fuerte del HDMA?, pues que que tiene un acceso total a los registros del PPU1 y PPU2 durante el período activo, lo cual permite usar una cantidad muy notable de recursos gráficos sin que la CPU tenga que perder tiempo en gestionarlo, y eso, por fín es una ventaja (que ya era hora, porque todo parecían pegas).
Es por esto que un SFX como PPU3 hubiera sido algo monstruoso: Un SFX corriendo paralelamente al 65c816, y sin que apenas existan restriscciones, ni se estorben, hubiera aumentado el rendimiento gráfico exponencialmente. No quiero ni pensarlo xD
Tengo que indagar mas sobre el bus de 24 bits de la super, porque me parece escaso que con ese potencial solo tenga un poco mas de capacidad que el de la mega (a 256x224).
gasega68k escribió:En el snes la transferencia de DMA es fijo (como dices unos 165 o 166) sin importar la resolución, ademas no existe el modo de 320x224, solo 256 o 512 de ancho x 224 o 448 de alto, pero esos modos de hres(512x224, 512x448 o 256x448)se usó muy poco en juegos, el modo de 512 solo puede tener 2 backgrounds uno con 16 colores y el otro con 4 colores.
El Gen/MD tiene resoluciones desde 256x224 hasta 320x448.
Si, si existe un modo de 320x224, e incluso tambien uno de 400x300. El problema es que a esas resoluciones, el ancho de la pantalla aumenta de longitud, y el generador de imágenes tiene un bug en que a partir de 256, elimina el excedente de sprites por scanline (32 por línea, o 34 tiles) de dentro hacia afuera, y no al revés, por lo que, a resoluciones mayores que 256x224, era mas fácil que este bug hiciera de las suyas, y dar como resultado una imagen "rasgada" mas veces de las que gustaría.
Y esto sin contar con que 165.5 espacios de escritura a 320x224 (que es una resolución a la que hacen falta mas tiles/sprites para conformar la imagen), tal vez se hagan insuficientes (según el juego claro, pero la necesidad de un mayor ancho de banda siempre estará ahí).
Ciertamente, el DMA es lo peor que tenían las 16 bits caseras, porque eran terriblemente asíncronas. Y lo peor es que es un error que causa el driver, y ese es un error de planificación de quien lo ideó, y no de falta de potencia del DMA.
Según parece, el espacio de escritura durante la pantalla activa tiene que ver con el excedente de líneas de la resolución, es decir:
A 256x224, realmente la resolución total es de 256x312 en formato pal (256x224 de forma activa), y 256x262 en formato NTSC (de nuevo, 256x224 forma activa). Es un excedente que podría usarse durante la pantalla activa, y no se usa.
Bytes por línea es de ~ 1364/8 ~ 170.5
NTSCbytesPerFrame = (1364 * 38) / 8 = 6.479
PAL2bytesPerFrame = (1364 * 88) / 8 = 15.004
Tienes 15 espacios de escritura muy majos que tiras por la borda, porque el ancho de banda del HDMA ni de coña equivale a eso (y encima no sirve para transferir tiles/sprites).
Y esto sin hablar de que, si son máquinas habilitadas para trabajar con resoluciones superiores, y por lo tanto el DMA aumenta su ancho de banda para proporcionar los bytes por línea suficientes (mas el excedente), ¿POR QUÉ BAJAN SU CAPACIDAD APOSTA CUANDO SE TRABAJA EN RESOLUCIONES INFERIORES?, ¿por qué no se trabaja a 256x224 con el excedente de 176/224 líneas, si precisamente el DMA está habilitado para ese ancho de banda, y por lo tanto puede existir esa resolución?. Eso no es un error de hardware, es una limitación impuesta adrede.
Y en megadrive sucede lo mismo, de forma innecesaria. El límite de sprites baja de 80 a 64 cuando bajas la resolución de 320x240 a 256x224. ¿Por qué?, ¿se podría solventar reescribiendo la bios y los drivers?.
Manveru Ainu escribió:Lo de forzar el vblank queda fuera de mis conocimientos, pero si es compatible con el resto del código el poder mandar 512 tiles suena brutal.
Tienes 16/18 espacios de acceso durante la pantalla activa. Espero que alcance
![[+risas]](/images/smilies/nuevos/risa_ani3.gif "más risas")
¿A cuántos tiles se supone que equivale eso? (en na transferencia a VRAM en período activa).
![[Ooooo]](/images/smilies/nuevos/sorprendido_ani1.gif "Oooooo")
