No sólo son un memcpy hardware; los canales DMA acceden al cartucho y RAM, cuando el bus está libre. Cuando la CPU no está utilizando el bus de memoria. Eso es así con todos los DMAs, desde MegaDrive, microcontroladores, hasta los PCs que tenéis delante.
Recordad que en estas máquinas, la RAM era aún mucho más rápida que la CPU y los adaptadores de vídeo y sonido; y por eso metieron DMAs, blitter, sprites hardware todo cuanto pudieron. Para aprovechar el tiempo que estaba libre la RAM. Esta manera de diseñar computadores encuentra su límite técnico en el Falcon de Atari.
En MegaDrive la RAM pese a ser más lenta que en un ST, tiene mayor ancho de banda; al ser toda RAM estática y no necesitar refresco (se ahorraron la circuitería y la lógica para refrescar, que no es nada sencillo, a costa de una RAM más cara). Quizá por eso acabaron dejando la VRAM en sólo 64 KB, porque al ser SRAM es más cara. Por cierto, que el VDP funciona a 13 MHz, y cuando construye un fotograma, pinta los sprites línea a línea... la memoria donde el VDP construye la información de la línea (es interna al VDP, hay espacio para dos líneas, la que pintas, y la que sale por el vídeo) para que a continuación la pinte en pantalla el DAC de salida de vídeo, es de 256 bits a 8 MHz (éste dato si me ha parecido sorprendente).
Las capacidades DMA se encuentran sólo en el adaptador de vídeo, el VDP; tiene una caché de instrucciones de 256 bytes. Puedes organizartelo para que sea todo instrucciones relativas a transferencia DMA, para que se encadenen ellas solitas; siendo el resultado final más potente y complejo que un sólo memcpy; es como encadenar múltiples memcpy. Como recomendación, no exceder 200 tiles por frame.
Los gráficos, cuando están comprimidos; deben ser transferidos del cartucho a la RAM del 68000 (éste trabajo lo hace el 68000), el 68000 lo descomprime tile a tile en su propia RAM, y escribe la órdenes DMA en la caché del VDP; el VDP empieza a copiar a la VRAM mientras el 68000 aún sigue descomprimiendo tiles.
Por supuesto, no es muy recomendable utilizar compresión ni para animaciones ni para el mapeado; salvo que el mapeado avance muy lentamente; o vayas a hacer grandes cambios de tiles en la VRAM y se vayan a quedar ahí bastante tiempo.
La compresión en el sonido es bastante útil
Gracias a esto último, la Misión 1 del port de Metal Slug de Atari STE, cabe en tan sólo 1 MB en su versión MegaDrive.
Y a lo que comentaba Chipan; hay unos marrones muy gordos respecto al adaptador de vídeo de MegaDrive; sobretodo cuando utilizas sprites estáticos (todos los frames cargados en la VRAM) y a cómo gestionas los procesos / sprites que se van viendo en pantalla...
por poner un ejemplo: como un sprite alguna vez sólo dure 1 fotograma... ya puedes rezar, porque hacen falta varias pasadas de los datos de un sprite a través de la lógica del VDP en frames sucesivos; en este ejemplo se producirían bugs gráficos y atascos del bus de memoria (con retardo, para confundir más si cabe) provocados por un malfunciomiento del VDP y es irrecuperable.
Unos pantallazos nuevos, para abrir boca:
Por cierto, el sonido 100% digital sampleado y comprimido, ¡suena como los ángeles!
Iniciado por Drumpi
Hombre, por temas de espacio, no sé hasta qué punto los gráficos ocupan tanto que, comprimidos, no quepan en un cartucho grande de MD. El SotN tiene muchos diálogos y efectos sonoros (aparte del sonido en CD), pero en cuestión visual... al menos en lo que respecta a tiles, lo mismo es posible que quepa todo. Ya los enemigos grandes o los fondos es otro cantar, pero a las malas, puede hacer como hace todo el mundo, y pasar el desarrollo a Mega CD: es el comodín cuando un proyecto crece demasiado
Citar
la latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.
Marcadores