MASTERMAPPER

Avatar de Usuario
antoniovillena
Mensajes: 2621
Registrado: 27 Sep 2015, 20:41

Re: MASTERMAPPER

Mensaje por antoniovillena » 15 Nov 2016, 15:26

Uto escribió:
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.
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.
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ó: 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 :lol: :lol:


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.
Uto escribió:
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.
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á
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ó: 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 :-)
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ó:
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.
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?
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 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
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ó: 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.
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:
  1. Escribir una serie de tutoriales sobre cómo acceder a los 512K de RAM
  2. Hacer un sencillo fork del firmware (cambiaría sólo una instrucción) que arranque en rooted todas las ROMs
  3. Alternativamente al paso anterior puedes preguntarle a McLeod cómo cambiar el core para desvincular los 512K del LOCK, así evitas posibles briqueos

Avatar de Usuario
Uto
Mensajes: 1394
Registrado: 17 Dic 2015, 16:39

Re: MASTERMAPPER

Mensaje por Uto » 15 Nov 2016, 18:06

antoniovillena escribió: 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.
Desde luego.
antoniovillena escribió: 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.
No es la del ZX-Uno la que es mala, es la del DivIDE. De hecho la de ZX-Uno es tan sencilla en esto de cambiar los bancos que es lo que me lleva a pensar que es mucho mejor usar la RAM con mastermapper que montarte un driver super complicado para acceder a parte de la RAM con la paginación del 128K, parte con la paginacion horizontal, y parte con el DivMMC, y encima dejarte 128K sin usar (o unos pocos menos si respetas los slots de las ROM).


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.
No es el caso de Sword of Lanna, solo carga fases por lo que sería perfectamente posible hacer un .tap, aunque sería un coñazo usarlo por EAR. Sus autores no lo han hecho así porque han decidido aprovechar las ventajas de almacenamiento rápido de los Spectrum modernos, como el DivIDE o el Dandanator.
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.
¿Cuantos había para el modo radastan cuando se puso? ¿Cuantos había para los modos Timex? Cero ambos ¿no? Y ahora hay uno de cada, con lo cual se han hecho cosas porque se podía hacer. Si hay un tracker de música que no puede correr en 128K ya hay una razón para poner más.
No soy solo yo. Somos 3 los que tomamos las decisiones técnicas (Quest, McLeod y yo). Y podemos equivocarnos.
Era un "tú" genérico Antonio, quiero decir que si hay algo que está ahí y está capado porque alguien, o "alguienes" piensan que no hace falta, y esos alguienes se equivocan, nunca se hará nada porque está capado. Sin embargo si se deja abierto porque esos alguienes lo deciden así no afecta en nada a lo que hay, y puede que se haga algo, o puede que no, pero nadie se encontrará con una barrera artificial.
[*]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[/list]
No hay una manera razonable de acceder a los 512K en ZX-Uno a dia de hoy, es una locura arrancar en rooted, y no quiero cambiar el core, lo que sugiero es que se cambie el core oficial porque como está no es razonable. Lo haría yo mismo y le pasaría los cambios a mcleod si no tuviera que dedicar 10 años de mi vida a aprender la cuarta parte de lo que sabe él de electrónica :lol:

¡Ah! Y ante todo: cuando sugiero esta u otras cosas, aun en el caso de que se me diga que tengo razón, no espero que se implemente/cambie/haga de inmediato, ni en el siguiente año. Para eso luego están las prioridades y lo mismo no se hace nunca, quien sabe.
Última edición por Uto el 15 Nov 2016, 18:09, editado 2 veces en total.

Avatar de Usuario
Haplo
Mensajes: 368
Registrado: 05 Oct 2015, 13:51
Ubicación: Ciudad Real

Re: MASTERMAPPER

Mensaje por Haplo » 15 Nov 2016, 18:07

Lo del bit LOCK separado para impedir/habilitar el acceso a los 512K pero no a la flash, me parece lo más sencillo. (Todo esto visto desde mi nulo conocimiento de cómo hacéis estas maravillas :mrgreen:)

Imagino que cuando se pueda, haya ganas y tiempo, se considerarán ésta y otras sugerencias de mejora.

Avatar de Usuario
Alki
Mensajes: 129
Registrado: 13 Sep 2016, 17:50

Re: MASTERMAPPER

Mensaje por Alki » 16 Nov 2016, 23:22

Creo que somos unos cuantos los que leemos este hilo desde la sombra y la ignorancia, pero bajo mi punto de vista, estoy con Haplo en que poner el lock de escritura en flas por separado sería una buena opcion...

Responder