Por esa razón supongo que McLeod lo tendrá habilitado. Cada vez que se implementa algo nuevo en el ZX-Uno yo voy por detrás en el desarrollo del firmware. Mientras tanto McLeod saca un comando ESXDOS para probar dicha mejora. Bajo mi punto de vista estas utilidades deberían funcionar en ROMs rooteadas de la misma forma que lo hacen las que acceden a la flash.Uto escribió:No estoy de acuerdo, es muy útil tenerlo así, de hecho no existiría .ZXUC si no fuera por eso, porque la existencia de esos registros modificables le dan sentido y gran parte de sus menús afectan precisamente a eso. De hecho yo liberaría algunos bits de MASTERCONF también, todos menos el LOCK que impide escribir en la SPI Flash, que me parece muy razonable.antoniovillena escribió:Pues no debería. Tanto DEVCONTROL como DEVCTRL2 deberían ser accesibles sólo desde la BIOS. En este caso es un error de implementación.
Uto escribió: Y nada de lo que he dicho impide eso, todo esto queda oculto para el común de los mortales que se dedica a jugar y no sabe ni que existen los registros de ZX-Uno. Otra cosa es que se impida a programadores utilizar funcionalidades de ZX-Uno o se le pongan barreras (como arrancar con rooted) que harán que su esfuerzo sea en vano, porque nadie va a usar juegos que requieran rooted.
La prueba de que esto está oculto es que no habla nadie en este hilo más que tú y yo, porque casi nadie entiende de que hablamos
Todo esto está documentado en la wiki. Otra cosa es que nadie se haya leído lo wiki o que los desarrolladores no le vean potencial. Yo no veo la room rooted como una barrera. Tal vez el problema esté en el nombre. O tal vez lo que se necesite es otro bit de LOCK separado impedir el acceso a los 512K, de tal forma que se pueda acceder a toda la RAM y no a la flash.
La información no es mala, lo que pasa es que está en la wiki de una forma técnica. Esta información está para el que la quiera usar, ya sea hacerte tu propio firmware, un core que sea compatible o para desarrolladores de juegos. No hay ninguna advertencia específica para desarrolladores de juegos, está claro que si quieren hacer un juego con esta documentación sólo va a funcionar en un ZX-Uno.Uto escribió:Si la información sobre el uso de esa RAM es tan mala como la que hay de DivIDE, o se ponen trabas para usarla como en ZX-Uno, estoy de acuerdo contigo en que nunca ocurriráantoniovillena escribió: De la misma forma que no suelen hacerse juegos que use la RAM adicional del DivIDE, tampoco se harán usando los 512K del ZX-Uno.
Este juego se ha hecho antes para Dandanator, por lo que tampoco es un desarrollo exclusivo para DivIDE. También hay utilidades específicas para DivIDE como los reproductores de video de McLeod. En los juegos lo que se busca es compatibilidad. Si puedes hacer un juego multicarga y meterlo en un TAP, es compatible tanto para la gente que tenga DivIDE como la que no lo tiene. Ahora bien, si el juego está cada 10 segundos leyendo de la SD ya estamos hablando de otra cosa, y por lo tanto aquí si estaría justificado hacerlo sólo para DivIDE.Uto escribió: Hasta ahora tampoco se hacían juegos que utilizaran la tarjeta SD del DivIDE para guardar datos, y ahí tienes Sword of Lanna que lo va a hacer en su versión ESXDOS. ¿Por qué lo va a hacer? Porque se puede. ¿Por que nadie usará los 512K del ZX-Uno ni hoy ni dentro de 10 años? Porque no se puede
En 400K de código/datos que no escriban en la flash sería prácticamente imposible que se briqueara. Las rutinas de escritura de flash son lo suficientemente largas y complejas como para que no se puedan dar de forma aleatoria.Uto escribió:No solo es pegarse un tiro en el pie, porque ese mensaje va a echar atrás a muchos, sino que es muy peligroso. En .upgrade - que ocupa 1K - tenias un bug que podía brickear el ZX-Uno. ¿Qué no podrá haber si hay 400K de código/datos?antoniovillena escribió: Si lo quiere hacer, pues con poner un mensaje como en .romsupgr diciendo que arranque con modo rooted es suficiente, tampoco es como tirarse un tiro en el pie.
Y de esos clones, ¿cuántos programas existen que usen esa memoria extendida? Porque McLeod intentó implementar algo y preguntando a unos rusos sólo dimos con un programa (que ni siquiera era un juego sino un tracker de música) que necesitase más de 128K.Uto escribió: No veo por qué es más deseable extender el modo Radastaniano, el TurboSound, el ULAPlus, que la memoria. Ya ha habido hace muchos años clones de Spectrum con más memoria, mucho antes de que existiera ULAPlus o Turnbosound
No soy solo yo. Somos 3 los que tomamos las decisiones técnicas (Quest, McLeod y yo). Y podemos equivocarnos. Si tanto potencial le ves puedes hacer varias cosas:Uto escribió: Vale, tu no le ves mucho potencial. ¿Y si otro sí se lo ve? ¿No podrá usarlo porque tú no le ves potencial?
Sigo diciendo que MASTERMAPPER se parece mucho más al modo Radastan que al escribir en la flash, y que debería tratarse mucho más como el modo Radastan a nivel registros que como el escribir en FLASH, o al menos debería tener su propio bit, porque juntar las dos cosas es peligroso, porque activar MASTERMAPPER lleva inevitablemente a activar escritura en flash.
- Escribir una serie de tutoriales sobre cómo acceder a los 512K de RAM
- Hacer un sencillo fork del firmware (cambiaría sólo una instrucción) que arranque en rooted todas las ROMs
- Alternativamente al paso anterior puedes preguntarle a McLeod cómo cambiar el core para desvincular los 512K del LOCK, así evitas posibles briqueos