MASTERMAPPER

[Uto]

Hola,

Sigo por aquí una conversación que teníamos por whatsapp, pero que quedó interrumpida anoche porque me quedé dormido O:-)

La cuestión era por qué el registro MASTERMAPPER (que permite mapear cualquier slot de RAM del ZXUno en la zona que ve el Spectrum) solo funciona en modo boot, y por tanto no puede usarse una vez arrancado el Spectrum. Esta es la respuesta de mcleod, que llegó cuando yo ya dormía:

Porque parte de esos 512KB se usan para guardar la ROM del sistema, La ROM de ESXDOS y la RAM de DivMMC y por tanto no deberían poder estar disponibles como simple RAM para el usuario

A priori me parece correcta, al menos por la parte de las ROMs, porque a la RAM del DivMMC ya podemos acceder por otro lado. ¡Pero hay tantas cosas en el Spectrum que si haces algo mal se cuelga! Prueba a escribir a boleo en las variables del sistema en basic, a cambiar la pila sin tener cuidado en assembler, a hacer un salto a una dirección de la ROM errónea por error,etc.

Sinceramente me parece que se peca de exceso de celo en este asunto, porque a diferencia de la escritura en la flash, que es un peligro real, equivocarse al usar MASTERMAPPER lo más que puede llevar es a tener que hacer un master reset ¿no? O sea, lo mismo que hacemos en un Spectrum real cuando la cagamos y se nos cuelga.

Sinceramente yo dejaría acceso libre a MASTERMAPPER y que lo use quien o necesite o quiera hacerlo, y como mucho si os parece peligrosa la escritura en ROM, que sea necesario activar un nuevo bit de DEVCRTL2 para poder escribir en ciertos slots (algo en plan EnROMWrite). Ni siquiera quitaría del todo la escritura en los bancos de ROM, porque puede que un programador necesite esa memoria y pueda prescindir de las ROMs así que no le importe reescribirlas, o incluso realice escrituras intencionadas para dar un servicio (como el pokeador automático de Microhobby).

[Uto]

Nota: soy consciente de que si un programador modifica la ROM un soft-reset no la recompone, pero eso es tan fácil como que el programador que lo haya hecho ponga en $0000 una rutina que simplemente muestre en pantalla "Esta ROM ha sido modificada, por favor haga un master-reset".

[antoniovillena]

Por esa razón creamos la posibilidad de rootear ROMs. En una ROM rooteada puedes volver a modo bootm=1 y modificar MASTERMAPPER a tu antojo. Digamos que durante la BIOS tienes un Superspectrum. Lo normal es que cuando la BIOS le da paso a una ROM se convierta en un Spectrum, pero tienes la puerta trasera de decirle a la BIOS que en determinadas ROMs siga siendo un Superspectrum y por lo tanto que el programador tenga acceso a todos los recursos de la máquina.

[Uto]

Por esa razón creamos la posibilidad de rootear ROMs. En una ROM rooteada puedes volver a modo bootm=1 y modificar MASTERMAPPER a tu antojo. Digamos que durante la BIOS tienes un Superspectrum. Lo normal es que cuando la BIOS le da paso a una ROM se convierta en un Spectrum, pero tienes la puerta trasera de decirle a la BIOS que en determinadas ROMs siga siendo un Superspectrum y por lo tanto que el programador tenga acceso a todos los recursos de la máquina.

Sigo sin entenderlo. ¿por qué una funcionalidad que no es peligrosa y que no afecta en compatibilidad si no la usas debe necesitar la una ROM rooted?
Es como si para usar modo Radastan, la interrupción raster, el Turbosound (que son también funcionalidades de un Super Spectrum ) hubiera que usar la ROM rooted. No le veo sentido.

Además es contraproducente, porque si alguien llega a necesitar los 512K, o 400K para algo, se verá obligado a detectar ROM rooted y decirle al usuario que arranque con ella si no está, y en ese caso además de activarse la funcionalidad inocua de MASTERMAPPER, quedará activada la funcionalidad nada inocua de escribir en la flash. Es decir, todo programa que quiera usar la RAM linealmente, tendrá el peligro de escribir, aunque sea por error, en la flash.

En fin, que tal como yo lo veo la funcionalidad de MASTERMAPPER está al nivel de la del modo Radastan, y no al nivel de la de escribir en flash, por eso no entiendo lo del boot mode y el rooted. Ciertamene es ligeramente más delicada que el modo Radastan, y el que la use debe tener más cuidado, pero meterla en el mismo saco que la escritura en flash me parece muy paternalista, y un recorte de las funcionalidades del ZX-Uno importante (y eso que aun no hay ZX-Unos con 4Mb de RAM)

Puestos a considerarlo "peligroso" yo mas que requerir BOOT mode le pondria un "EnMasterMapper" a DEVCTRL2 y que por defecto no se pueda usar, pero se pueda activar a voluntad.

[antoniovillena]

Lo de que no es peligroso es relativo. Es menos peligroso que escribir en flash, pero estás dando acceso al mapa de memoria completo de la máquina. Y ese mapa incluye poder escribir en zonas que normalmente son ROMs, como la del spectrum y la del esxdos. Alguien podría modificar la ROM del esxdos para infectar el MBR de la SD. El modo Radastaniano por ejemplo era accesible siempre, y en un momento dado tuvimos que hacerlo configurable por la BIOS. No fue por motivos de seguridad sino de compatibilidad (con un modo Timex en concreto), pero pasa lo mismo que con la ROM rooted. Puedes elegir arrancar una ROM con modo Radastaniano activado o desactivado de la misma forma que puedes arrancar una ROM rooteada o sin rootear.

[Uto]

Para infectar el MBR no hace falta parchear ninguna ROM, cualquier programa puede hacerlo usando las funciones de ESXDOS de acceso directo a disco (DISK_READ y DISK_WRITE), y eso se puede hacer sin rooted ni nada.

Y eso si hablamos de virus pensados para luego liarla en Windows, que si hablamos de infectar .tap con virus hechos expresamente para ESXDOS, es más fácil todavía. Y una vez hecho el virus que infecta taps sin hacer nada visual ¿que costaría hacer que ese virus que infecta .tap también escriba en la MBR, de modo que si alguien le pasa ese tap a otra persona le infecte también la MBR de su tarjeta? Nada.

En fin, bloquear MASTERMAPPER por eso es como tratar de tapar una vía de agua del tamaño de un botón de camisa cuando hay agujeros del tamaño de una bala de cañon por todas partes, al tiempo que se impiden usos lícitos y buenos de la funcionalidad

Es más, mientras MASTERMAPPER requiera rooted, es una puerta abierta para que cualquiera que quiera usarlo se pueda ver afectado por un virus que no escriba en la MBR, sino en la flash (a mala leche para brickear, o con más mala leche aun, para perpetuarse modificando las zonas de las ROMs de modo que ni un master reset le afecte).

[antoniovillena]

Para infectar el MBR no hace falta parchear ninguna ROM, cualquier programa puede hacerlo usando las funciones de ESXDOS de acceso directo a disco (DISK_READ y DISK_WRITE), y eso se puede hacer sin rooted ni nada.

Y eso si hablamos de virus pensados para luego liarla en Windows, que si hablamos de infectar .tap con virus hechos expresamente para ESXDOS, es más fácil todavía. Y una vez hecho el virus que infecta taps sin hacer nada visual ¿que costaría hacer que ese virus que infecta .tap también escriba en la MBR, de modo que si alguien le pasa ese tap a otra persona le infecte también la MBR de su tarjeta? Nada.

Vale, aquí tienes razón. He escogido un ejemplo malo.

En fin, bloquear MASTERMAPPER por eso es como tratar de tapar una vía de agua del tamaño de un botón de camisa cuando hay agujeros del tamaño de una bala de cañon por todas partes, al tiempo que se impiden usos lícitos y buenos de la funcionalidad

Es más, mientras MASTERMAPPER requiera rooted, es una puerta abierta para que cualquiera que quiera usarlo se pueda ver afectado por un virus que no escriba en la MBR, sino en la flash (a mala leche para brickear, o con más mala leche aun, para perpetuarse modificando las zonas de las ROMs de modo que ni un master reset le afecte).

Digamos que hay un problema y 3 puntos de vista:

• Restrictivo
  Esto sería que al salir de la BIOS se bloquee siempre y nunca podamos acceder a los 512K. A fin de cuentas es un modo de paginación que nos hemos inventado y no hay software (aparte de la BIOS) que lo soporte.
• Permisivo
  Acceder siempre a los 512K. Es la postura que mantienes tú.
• Flexible
  Es una forma de contentar los 2 puntos de vista anteriores pero a costa de complicar el hardware. Es la forma que lo hemos implementado.

De la misma forma que en un spectrum 128K bloqueas la paginación a 48K al seleccionarlo en el menú, nosotros queremos que exista la forma de que no puedas acceder a los 512K, pero con la opción de que exista otro modo en el que accedas a 512K. Si lo que quieres es una máquina con acceso a todo, no uses la BIOS. En lugar de la BIOS pones una ROM de 48K y tendrás todos los recursos del core a tu disposición. La BIOS está pensada para "capar" el Superspectrum y tener la posibilidad de arrancar distintos modelos de spectrum. De lo contrario, si quieres arrancar distintos modelos, tendrías que tener un core para cada modelo.

[Uto]

De la misma forma que en un spectrum 128K bloqueas la paginación a 48K al seleccionarlo en el menú, nosotros queremos que exista la forma de que no puedas acceder a los 512K, pero con la opción de que exista otro modo en el que accedas a 512K.

Cuando en un Spectrum 128K bloqueas la paginación a 48K al seleccionarlo, el programador puede luego desbloquearla porque está en DEVCTRL que es totalmente accesible, y viceversa. Es decir, un programador avispado podrá sin ningun problema cambiar a modelo de 128K si arranca con 48K y viceversa, activar la paginacion de los Timex aunque la ROM arrancada sea sin ellos, activar el modo Radastaniano aunque la ROM arrancada lo tenga desactivado, etc. ¿Que tiene de diferente la posibilidad de usar toda la RAM? ¿No sería más equivalente poner un bit "EnMastermapper" en DEVCTRL2 similar a los anteriores que por defecto lo tenga disabled pero si alguien que sabe lo que hace quiere activarlo y usar MASTERMAPPER lo active, que requerir modo rooted que es una opción pensada para otra cosa?

No acabo de ver qué diferencia el uso de la memoria extra del uso de modos Timex, Turbosound, etc. y todos ellos tienen un Enable/Disable que se puede modificar por software sin necesidad de ser rooted.

Si lo que quieres es una máquina con acceso a todo, no uses la BIOS. En lugar de la BIOS pones una ROM de 48K y tendrás todos los recursos del core a tu disposición. La BIOS está pensada para "capar" el Superspectrum y tener la posibilidad de arrancar distintos modelos de spectrum. De lo contrario, si quieres arrancar distintos modelos, tendrías que tener un core para cada modelo.

Yo no quiero nada, como siempre mi consulta es teórica

Simplemente me pregunto por qué se dota a ZX-Uno de una posibilidad y luego se hace virtualmente imposible utilizarla.

Si la BIOS y/o el core oficial no lo permiten, es inútil crear nada que lo use, porque tienes dos opciones:

1) Decir al un usuario que para utilizar tu juego tienen que arrancar con ROM rooted, que es como pegarte un tiro en el pie, porque no lo hará nadie, y el que lo haga, estará corriendo un peligro, porque en un juego de 400K hay muchas más posibilidades de tener un bug que por despiste escriba en la flash y ... )

2) Decir al usuario que cambie la BIOS de su ZX-Uno por una que le das tú para poder correr tu juego (esto ya sí que no lo hará nadie)

[antoniovillena]

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.

Nuestra intención es ocultar en la medida de lo posible los aspectos técnicos de la máquina como son estos puertos específicos y el modo de paginación del ZX-Uno. A fin de cuentas los que se compran el aparato quieren algo lo más parecido a un spectrum. Y lo normal es que los desarrolladores hagan juegos para 48K o para 128K de forma que sean lo más compatible posible. 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 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.

Otra cosa es por ejemplo el modo Radastaniano. En este caso sí es algo que es deseable extender. Por eso hicimos el concurso y es un modo que ya implementan otros cores como el de Next y el de Jeff Braine.

Yo personalmente no le veo mucho potencial a tener paginados más de 128K en un spectrum. Teniendo acceso a DivIDE/DivMMC puedes hacer los juegos tan grandes como quieras sin restringir tu juego a una máquina en concreto.

[Uto]

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.

Nuestra intención es ocultar en la medida de lo posible los aspectos técnicos de la máquina como son estos puertos específicos y el modo de paginación del ZX-Uno. A fin de cuentas los que se compran el aparato quieren algo lo más parecido a un spectrum. x

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

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á.

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

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?

Otra cosa es por ejemplo el modo Radastaniano. En este caso sí es algo que es deseable extender. Por eso hicimos el concurso y es un modo que ya
implementan otros cores como el de Next y el de Jeff Braine.

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.

Yo personalmente no le veo mucho potencial a tener paginados más de 128K en un spectrum. Teniendo acceso a DivIDE/DivMMC puedes hacer los juegos tan grandes como quieras sin restringir tu juego a una máquina en concreto.

Vale, tú 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.