Gracias. No conocía el CPC-CPLINK2, pero ahora que lo veo, tal vez pueda beneficiarse de los modos DMA.
Documentación actualizada, añadiendo el uso del modo DMA 2D: PROGRAMMING.md · master · doragasu / romba-pi-src · GitLab
Creo que tal vez debería añadir los programas en BASIC que uso para las pruebas para complementar las explicaciones sobre cómo usar los modos DMA.
Sí, probablemente ayudaría con el DMA, pero tuve que usar 8 GPIO para el lado de datos de la PI (GPIO32..39), y los GPIO restantes no tolerantes a 5 V (40..47) también dan servicio a la PI. Así que probablemente me falten algunas señales del bus CPC.
Por el momento solo estoy usando una placa de desarrollo.
Documentación actualizada con mucha más información:
- Información más fácil de entender (espero) sobre cómo usar el modo DMA 2D.
- Lista de registros DMA actualizada.
- Se añadieron listados de BASIC de ejemplo para leer el ratón y realizar transferencias DMA lineales y 2D.
- Se añadió información sobre cómo hacer rellenos DMA y también transferir desde la memoria interna del CPC.
Como siempre, puedes leerlo en el repositorio: PROGRAMMING.md · master · doragasu / romba-pi-src · GitLab
El debate reciente sobre Another World, en el que se hablaba de cómo el juego funciona con una simple máquina de estados que solo depende de una rutina rápida de relleno de polígonos, me hace pensar que sería un buen candidato para experimentar con las capacidades de DMA de este cartucho.
En su estado actual, los rellenos por DMA pueden resultar útiles para dibujar rectángulos (incluidas líneas horizontales y verticales). Pero más allá de eso, puede que no sea de gran ayuda.
¿Seguro que se puede construir un polígono a partir de líneas horizontales? ¿O hay demasiada sobrecarga como para que valga la pena hacer algo así?
Los antiguos motores 3D por software renderizaban triángulos de esa forma. Dividían los triángulos verticalmente y luego dibujaban líneas horizontales.
No estoy seguro de si el DMA resulta más útil con transferencias de datos masivas que con datos muy específicos y en constante cambio.
Tienes que hacer algunos OUTs para cambiar las coordenadas de relleno y la longitud, y luego iniciar la transferencia. Así que para dibujar unos pocos píxeles, podría ser más rápido simplemente escribirlos directamente en el búfer.
Podrías hacer cosas como renderizar polígonos en el RP2350 y transferirlos mediante DMA, pero entonces la policía del CPC llamaría a tu puerta ![]()
Incluso podrías hacer cosas como ejecutar DOOM en el RP2350, cuantizado para la paleta de colores y la resolución del CPC, y transferir los fotogramas al CPC. La transferencia de una pantalla completa tarda unos 16,4 ms, por lo que aplicaciones como un reproductor de vídeo a 50 FPS también serían posibles (además tienes hasta 16 MiB de ROM para almacenar el vídeo).
Estoy restringiendo las capacidades DMA del cartucho a lo que un blitter típico era capaz de hacer en aquella época. Pero poder cambiar todo el contenido de la pantalla del CPC en menos de un fotograma permite hacer cualquier tipo de acelerador, si no te importa que el renderizado no lo haga el Z80.
¡Tiene buena pinta!
Me encantan las capacidades de DMA; ¡marcarían una gran diferencia para conseguir una tasa de fotogramas fluida! ![]()
Si sacas una tanda de ellos, ¡sin duda me quedo con uno!
¡Las funciones de DMA me parecen muy atractivas! ¡Sigan así! Una pregunta que tengo es: ¿podría el 2350 ser una placa hija (por ejemplo, un módulo central) que se pueda soldar? Eso simplificaría muchísimo este montaje.
