Hola
Estaba pensando, en ponerle un Z80C a 10Mhz, externo al cpc. Se compondría de 16ks de rom con rutinas gráficas y de cálculo, 48 ks de ram, donde poder poner gráficos .. etc. y las 16ks de ram superiores del CPC accesibles como banco en las 16ks superiores del procesador externo.
Desde el CPC, podríamos conmutar los 48ks del externo para acceder y escribir instrucciones a modo de psudocódigo. De ésta forma, podríamos hacer que el Z80 externo pintase y generase la parte gráfica de un juego, mientras la CPU interna se dedica a otras cosas.
Yo lo veo curioso el tema, porque podría hacerse un juego con enemigos especialmente "inteligentes" por poner un ejemplo; donde la "inteligencia" sería generada por el procesador interno y la parte gráfica pintada por el externo a pantalla del CPC completa.
igual es una chorrez, pero bueno.. sería un CPC con procesador dual, uno de 4Mhz y otro a 10Mhz.
saludos !!!
Ampliar el CPC haciendolo biprocesador ?
- rochete
- 16 bits

- Mensajes: 232
- Registrado: 24 Jun 2006 01:02
- Ubicación: VALENCIA
Ampliar el CPC haciendolo biprocesador ?
VoIP para operadores
http://www.tucall.com
http://www.tucall.com
- na_th_an
- 256 bits

- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
En teoría debería estar muy bien. El problema viene donde siempre: la sincronía y la comunicación entre micros. Al tener los micros velocidades distintas y no multiplos entre sí, habría que establecer un protocolo de comunicación por hand-shake o algo parecido, y emplear buffers en los buses de comunicación. Otra solución sería tratarlos como dispositivos independientes que se comuniquen entre sí por puertos de E/S (como hace el Z80 del MSX con el procesador de gráficos, por ejemplo), aunque entonces habría que definir bien una configuración de amo/esclavo.
Programar para dos micros a la vez sin que haya especialización pura de uno de ellos (un micro sólo para gráficos o sonido, por ejemplo) es complicado. Fue una de las cosas que hizo fracasar a la Sega Saturn: programar los dos micros para que trabajasen en conjunto era complejo y la mayoría de los desarrolladores acababan haciendo programas para uno solo de los CPUs, desaprovechando mucho el potencial de la máquina. Y te hablo de dos SH2 idénticos, imagínate si encima hubieran sido de distintas velocidades.
Sin embargo, si planeas emplear el dispositivo solo para gráficos o solo para sonido, o lo que sea, o como esclavo puro precalculando cosas que luego el otro micro (el principal) pueda usar tomándolos de una zona común de memoria, perfecto. Otros casos serían demasiado complejos no ya de diseñar, sino de programar.
Programar para dos micros a la vez sin que haya especialización pura de uno de ellos (un micro sólo para gráficos o sonido, por ejemplo) es complicado. Fue una de las cosas que hizo fracasar a la Sega Saturn: programar los dos micros para que trabajasen en conjunto era complejo y la mayoría de los desarrolladores acababan haciendo programas para uno solo de los CPUs, desaprovechando mucho el potencial de la máquina. Y te hablo de dos SH2 idénticos, imagínate si encima hubieran sido de distintas velocidades.
Sin embargo, si planeas emplear el dispositivo solo para gráficos o solo para sonido, o lo que sea, o como esclavo puro precalculando cosas que luego el otro micro (el principal) pueda usar tomándolos de una zona común de memoria, perfecto. Otros casos serían demasiado complejos no ya de diseñar, sino de programar.
- rochete
- 16 bits

- Mensajes: 232
- Registrado: 24 Jun 2006 01:02
- Ubicación: VALENCIA
hombre..
Mi idea es más sencilla.
El segundo procesador estaría dedicado a refrescar la memoria superior los 16ks de video del CPC únicamente. Previamente habríamos cargado los gráficos, rutinas, mapa del juego.
Simplificando tanto, que para decirle que zona del mapa tiene que pintar, cambiaríamos solamente 2 bytes. Para decirle que situación es la del prota, otro byte, la posición en pantalla .. etc.
Eso se haría de forma tal, que cuando el segundo accediera a la ram del principal, éste estaría waiting como le sucede con el controlador crt.
Pero la verdad es que la idea incita a probar cosas.
El segundo procesador estaría dedicado a refrescar la memoria superior los 16ks de video del CPC únicamente. Previamente habríamos cargado los gráficos, rutinas, mapa del juego.
Simplificando tanto, que para decirle que zona del mapa tiene que pintar, cambiaríamos solamente 2 bytes. Para decirle que situación es la del prota, otro byte, la posición en pantalla .. etc.
Eso se haría de forma tal, que cuando el segundo accediera a la ram del principal, éste estaría waiting como le sucede con el controlador crt.
Pero la verdad es que la idea incita a probar cosas.
VoIP para operadores
http://www.tucall.com
http://www.tucall.com
- Beyker
- 128 bits

- Mensajes: 2204
- Registrado: 24 Dic 2004 01:49
- Ubicación: La vile du Barcelona
- Contactar:
- na_th_an
- 256 bits

- Mensajes: 11874
- Registrado: 22 Abr 2005 13:25
- Contactar:
Re: hombre..
O sea, como puro esclavo, como procesador gráfico. Éso sí es totalmente factible. Este micro ejecutaría funciones gráficas como respuestas a llamadas a una API, tal y como hacen los micros de las tarjetas gráficas.tecnoxarxa escribió:Mi idea es más sencilla.
El segundo procesador estaría dedicado a refrescar la memoria superior los 16ks de video del CPC únicamente. Previamente habríamos cargado los gráficos, rutinas, mapa del juego.
Simplificando tanto, que para decirle que zona del mapa tiene que pintar, cambiaríamos solamente 2 bytes. Para decirle que situación es la del prota, otro byte, la posición en pantalla .. etc.
Eso se haría de forma tal, que cuando el segundo accediera a la ram del principal, éste estaría waiting como le sucede con el controlador crt.
Pero la verdad es que la idea incita a probar cosas.