Va de Retro (Satanás) -- Versión 3.3 SSL

flopping escribió:Y no es mi intención convencer a nadie, simplemente son comentarios o reflexiones que hago, que no tienen por qué ser correctas, puedo estar perfectamente equivocado, pero bueno, por lo menos me ha hecho pensar, jejejeejje y ya no digo nada más, de esto, así que sigamos con el colour clash o abramos un hilo de debates diversos, que creo que igual tendría exito, jajajajajja.

No pasa nada flopping las reflexiones están siendo muy interesantes

ESTOY PENSANDOMELO, NO SE SI PROGRAMAR UNA EPROM O QUEMAR UN CD ¿HAN TU QUE HARIAS?

Tromponauta escribió:

flopping escribió:

Quili escribió:... ¿Por que se me ocurrio preguntar?

Entiendo que una EPROM es un medio de almacenamiento ¿Y si llenamos esa EPROM de fotos de Chewbacca?

porque no hicieron un post de semantica, FPGA, RPG, programación, ceros, unos y chewbacas?

Encuentrenme el post de PUZZNIC para hacerlo denuevo en colores sin CLASH ATTR... PUTO@S!!"!

Pues lo mismo deberíamos crear un hilo especifico pero yo es que ya me he perdido. Ahora veo pistas, sectores y hasta egipcios programando piedras. Me rindo !

Hablando del Attribute Clash, las implementaciones hardware y los trucos de programación, pensando en la aceleración por hardware tan bien conseguida que están implementando en el Next se me ha ocurrido que estaría bien poder implementar un "motor" bitfrost o nirvana por hardware, la duda es si sería suficiente con evitar la contención de memoria o haría falta DMA para hacer algo así.

Tromponauta escribió:Hablando del Attribute Clash, las implementaciones hardware y los trucos de programación, pensando en la aceleración por hardware tan bien conseguida que están implementando en el Next se me ha ocurrido que estaría bien poder implementar un "motor" bitfrost o nirvana por hardware, la duda es si sería suficiente con evitar la contención de memoria o haría falta DMA para hacer algo así.

Yo creo que valdria con un registro para poder cambiar la zona de memoria de los atributos. Asi simplemente tendriamos que cambiar ese registto a cada retrazo horizontal.

wilco2009 escribió:

Tromponauta escribió:Hablando del Attribute Clash, las implementaciones hardware y los trucos de programación, pensando en la aceleración por hardware tan bien conseguida que están implementando en el Next se me ha ocurrido que estaría bien poder implementar un "motor" bitfrost o nirvana por hardware, la duda es si sería suficiente con evitar la contención de memoria o haría falta DMA para hacer algo así.

Yo creo que valdria con un registro para poder cambiar la zona de memoria de los atributos. Asi simplemente tendriamos que cambiar ese registto a cada retrazo horizontal.

Poco a poco voy aprendiendo de hardware, pero me queda mucho como para poder "implementar algo en mi cabeza" ahí tengo el libro de la ULA y no consigo hacer un hueco para su estudio, así que de momento a imaginar me dedico. E imaginando pienso en ese registro como el que le dice a la ULA plus que juego de colores tiene que usar pero orientado a decirle a la ULA que zona de memoria tiene que leer para colorear los píxeles y el fondo, eso estaría muy bien como "modificación sencilla de implementar en una ULA" además de que podría convertirse fácilmente en "Canon" Spectrumero como creo que ha sucedido con la ULA+. Entiendo que aunque libraría al Z80 de mucha carga todavía le correspondería al micro controlar la temporización e informar a la ULA de los cambios de posición donde leer. La idea me gusta mucho por sencilla, aunque yo ya estaba pensando en automatizar toda la tarea por hardware para liberar totalmente al Z80 como una especie de temporizador integrado que modificase ese registro....

Tromponauta escribió:

wilco2009 escribió:

Tromponauta escribió:Hablando del Attribute Clash, las implementaciones hardware y los trucos de programación, pensando en la aceleración por hardware tan bien conseguida que están implementando en el Next se me ha ocurrido que estaría bien poder implementar un "motor" bitfrost o nirvana por hardware, la duda es si sería suficiente con evitar la contención de memoria o haría falta DMA para hacer algo así.

Yo creo que valdria con un registro para poder cambiar la zona de memoria de los atributos. Asi simplemente tendriamos que cambiar ese registto a cada retrazo horizontal.

Poco a poco voy aprendiendo de hardware, pero me queda mucho como para poder "implementar algo en mi cabeza" ahí tengo el libro de la ULA y no consigo hacer un hueco para su estudio, así que de momento a imaginar me dedico. E imaginando pienso en ese registro como el que le dice a la ULA plus que juego de colores tiene que usar pero orientado a decirle a la ULA que zona de memoria tiene que leer para colorear los píxeles y el fondo, eso estaría muy bien como "modificación sencilla de implementar en una ULA" además de que podría convertirse fácilmente en "Canon" Spectrumero como creo que ha sucedido con la ULA+. Entiendo que aunque libraría al Z80 de mucha carga todavía le correspondería al micro controlar la temporización e informar a la ULA de los cambios de posición donde leer. La idea me gusta mucho por sencilla, aunque yo ya estaba pensando en automatizar toda la tarea por hardware para liberar totalmente al Z80 como una especie de temporizador integrado que modificase ese registro....

Me quedo anonadado, con lo que habláis, por esta conversación quiero entender que se podría llegar a fabricar un dispositivo para corregir el attribute clash.

Quili escribió: Me quedo anonadado, con lo que habláis, por esta conversación quiero entender que se podría llegar a fabricar un dispositivo para corregir el attribute clash.

Sí y no. Habría que andar cortando pistas y soldando internamente. Un dispositivo externo se podría hacer solamente si ignoramos la salida de video del spectrum y hacemos una totalmente nueva. Esto es lo que hacen, por ejemplo, en el interface chroma.