ZX-Uno prototipo 2: seguimos dándole caña

[mcleod_ideafix]

No obstante acabo de hacer alguna prueba más, y parece que puede tener que ver con la ROM utilizada. No suelo usar la del +3 (que es la que se suele usar por defecto), y usándola ahora veo que no me ha fallado el reset en un buen rato. Sin embargo usando otras ROMs, como la del 128k español, +2 gris o SE Basic IV Anya, los cuelgues y cosas raras son muy muy frecuentes.

Vale: ya sé qué te pasa. No tiene que ver con el comportamiento del reset en sí, sino en la forma en la que Antonio organiza las ROM's que no son de 64K. Yo en el firmware que compilo lo cambio, pero no sé si él lo ha hecho en el repositorio.

Basicamente esto es lo que se debe hacer: TODAS las ROMs, sean del tamaño que sean, deben ocupar los 4 bloques de RAM, del bloque 8 al 11. La BIOS, si detecta una ROM más pequeña que 64K (o sea, que es de 16K o de 32K) la repetirá en memoria, y ese es el comportamiento que queremos.

Cuando se hace un reset, los registros de paginación también se resetean, por lo que la ROM la busca en la página 8, y no en ningún otro sitio. Si tienes configurada la BIOS para que cargue, por ejemplo, la ROM del 48K en la página 11, en cuanto hagas un reset, la hemos liado.

Si estás usando la BIOS 0.227, copia y pega esta versión del fichero aa000.bin . Modifícalo según tu selección de ROMs, y graba la SPI con él. Si te fijas, ahora en todas las macros se especifica que la ROM comienza en la página 8 de RAM y ocupa las 4 páginas.

Código: Seleccionar todo

        output  aa000.bin

        define  Issue2  $00
        define  Issue3  $10
        define  Tim48   $00
        define  Tim128  $08
        define  NonContended $00
        define  Contended    $04
        define  DisableDiv   $00
        define  EnableDiv    $02
        define  DisableNMI   $00
        define  EnableNMI    $01

      macro Generic  slot, crc1, crc2, cadena, par1, par2, par3, par4, par5, par6
        defb    slot, par1, par2, par3, par4, par5, par6, $ff
        defb    crc1>>24&255, crc1>>16&255, crc1>>8&255, crc1&255, crc2>>24&255, crc2>>16&255, crc2>>8&255, crc2&255
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defm    cadena
        block   64-($ & 63), $20
      endm

      macro Cart    slot, crc, cadena
        Generic  slot, (crc<<16 | $ffff), $ffffffff, cadena, 1, $08, 4, $04, $30, Issue3 | Tim48  | Contended | DisableDiv | DisableNMI
      endm

      macro R32K    slot, crc, cadena
        Generic  slot, crc, $ffffffff, cadena, 2, $08, 4, $04, 0, Issue3 | Tim128  | Contended | DisableDiv | DisableNMI
      endm

      macro OPENSE    slot, crc, cadena
        Generic  slot, crc, $ffffffff, cadena, 2, $08, 4, $04, 0, Issue3 | Tim128  | Contended | EnableDiv | DisableNMI
      endm

      macro R64K    slot, crc1, crc2, cadena
        Generic  slot, crc1, crc2, cadena, 4, $08, 4, 0, 0, Issue3 | Tim128  | Contended | DisableDiv | DisableNMI
      endm

      macro R32KDIV slot, crc, cadena
        Generic  slot, crc, $ffffffff, cadena, 2, $08, 4, $04, 0, Issue3 | Tim128  | Contended | EnableDiv | EnableNMI
      endm

      macro R64KDIV slot, crc1, crc2, cadena
        Generic  slot, crc1, crc2, cadena, 4, $08, 4, 0, 0, Issue3 | Tim128  | Contended | EnableDiv | EnableNMI
      endm


l0aa0   Generic  0, $1bfeffff, $ffffffff, 'ZX Spectrum 48K', 1, 8, 4, 0, 0, Issue3 | Tim48  | Contended | EnableDiv | EnableNMI
        R32KDIV  1, $A2394D6A,            'ZX 128K +2 grey EN'
        R64K     3, $5E9092D5, $BCAD774D, 'ZX +3e DivMMC'
        OPENSE   7, $bfd5c9e8,            'SE Basic IV 4.0 Anya'
        Cart     9, $1039,                'ZX Spectrum 48K Cargando Leches'
        Cart    10, $b818,                'Manic Miner (1983)'
        Cart    11, $15e7,                'Jet Set Willy (1984)'
        Cart    12, $7d63,                'Deathchase (1983)'
        Cart    13, $aafc,                'Planetoids (1982)'
        Cart    14, $7a69,                'Space Raiders (1982)'
        Cart    15, $4d5b,                'Misco Jones (2013)'
        Cart    16, $D573,                'Jet Pac (1983)'
        Cart    17, $5F6B,                'PSSST (1983)'
        Cart    18, $2318,                'Cookie (1983)'

        block   $1000-$

;  00-3f: index to entries
;  40: active entry
;  41: fast boot    0: Disable, 1: Enable
;  42: Check CRC    0: Disable, 1: Enable
;  43: DivMMC       0: Disable, 1: Enable
;  44: NMI-DivMMC   0: Disable, 1: Enable
;  45: Issue        0: Issue 2, 1: Issue 3
l0ab0   defb    $00, $01, $02, $03, $04, $05, $06, $07
        defb    $08, $09, $0a, $0b, $0c, $0d, $0e, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $ff, $ff, $ff, $ff, $ff, $ff, $ff, $ff
        defb    $00             ; active
        defb    $00             ; quiet
        defb    $01             ; checkcrc
        defb    $02             ; Issue
        defb    $02             ; Timing
        defb    $02             ; Contended
        defb    $02             ; DivMMC
        defb    $02             ; NMI-DivMMC
        defb    0   ; para que not implemented sea 0

; 64 entradas
;    00: slot offset
;    01: B= slot size
;    02: RAM offset     
;    03: B= ROM SRAM size
;    04: port 1ffd
;    05: port 7ffd
;    ...
;    10-1f: CRCs
;    20-3f: Name

        block   $2000-$


Excelente, lo probaré
Tampoco había comentado nada a pesar de ir viendo cambios en el SVN porque imaginaba que estabas aún en ello. Simplemente quería comentarlo por lo de ir pensando en cómo ponerlo en la BIOS, de cara al usuario y demás.

Y más cosas que aún no he contado Para todo ello habrá utilidades de línea de comandos para usar con ESXDOS, además de que Antonio implemente aquella funcionalidad que considere conveniente en la propia BIOS. El protocolo de joystick es seguro una de esas cosas.

Esto me recuerda algo: ¿veis conveniente añadir a la lista de protocolos el "protocolo" OPQAM? Es decir, que el josytick mapee a esas archiconocidas teclas. Dicho de otra forma, ¿hay algún juego que sólo soporte teclado, y que además la combinación que soporta sea esa y ninguna otra?

[Quest]

Basicamente esto es lo que se debe hacer: TODAS las ROMs, sean del tamaño que sean, deben ocupar los 4 bloques de RAM, del bloque 8 al 11. La BIOS, si detecta una ROM más pequeña que 64K (o sea, que es de 16K o de 32K) la repetirá en memoria, y ese es el comportamiento que queremos.

Genial, parece que es eso exactamente
De hecho tengo mi propia versión modificada del aa000.asm. La cambiaré por tu ejemplo adecuándola a mis ROMs. O mejor aún, puedo hacerme un genrom para que los TAPs para subirlas por EAR estén ya adecuados a esa estructura en RAM.

Y más cosas que aún no he contado Para todo ello habrá utilidades de línea de comandos para usar con ESXDOS, además de que Antonio implemente aquella funcionalidad que considere conveniente en la propia BIOS. El protocolo de joystick es seguro una de esas cosas.

He probado el Joyconf como comando ESXDOS y es una delicia en modo interactivo
En BIOS Podemos dedicarle una página entera a eso. Lo normal será configurarlo una vez para todo para que siempre que enciendas el ZX-UNO esté con tu config favorita, y sólo haya que cambiarlo puntualmente para algún juego/programa concreto.

Esto me recuerda algo: ¿veis conveniente añadir a la lista de protocolos el "protocolo" OPQAM? Es decir, que el josytick mapee a esas archiconocidas teclas. Dicho de otra forma, ¿hay algún juego que sólo soporte teclado, y que además la combinación que soporta sea esa y ninguna otra?

Pues... en realidad (y me temo que me dirás que no será tan fácil ) lo mejor sería una configuración personalizada de "emulación de teclas". Es decir, poder indicar libremente qué 5 teclas del teclado equivalen a cada una de las 4 direcciones + disparo del joystick. Así no hara falta andar con configs pre-preparadas para ciertas combinaciones como OPQAM que suelen ser comunes, pero no universales (hay otras con ZXWS o que el disparo es la barra espaciadora, u otras combinaciones raras como los mojonos en Ninjajar -aunque se puede elegir joystick, lo se ). Y ya sería la re-re-repanocha si te pudieras crear perfiles con sets de teclas personalizadas y activarlos a voluntad, aunque esto es 150% prescindible, evidentemente.

Es decir, por poner un ejemplo de cómo podría configurarse por comando ESXDOS:

JOYCONF -kk0 -jp0 -mOPQAM

Siendo: la "p" un nuevo tipo de "personalized keymap" o similar y -mLRUDF "map" de "L" left, "R" right, "U" up, "D" down, "F", fire.

¿Cómo lo ves? ¿Se complica mucho o es factible? Vamos, más configurable imposible queja no habrá.

[antoniovillena]

Yo, como siempre que llega el momento doy mi propuesta para "consolizar" el ZX-Uno. Como una imagen vale más que mil palabras ahí va.



La selección se hace a ciegas (a diferencia de los emuladores, aquí el OSD es costoso) y para ello se emplea el segundo botón del joystick. No hace falta decir que esto sólo funciona con joysticks Atari que tengan implementado un segundo botón "fuera de norma" en el pin 9. La pulsación simultánea del botón secundario con cualquiera de las 8 direcciones mapea a cada una de las semifilas del teclado (las semifilas de la izquierda están invertidas). La pulsación simultánea de los dos botones (independientemente de la dirección) selecciona OPQA Espacio y finalmente la pulsación única del segundo botón seleccionará el mapeado Kempston.

-- Actualizado 13 Jun 2015, 23:10 --

Sí, es culpa mía lo del reset. Para hacerlo más realista decidí meterlo sólo en la ROM 3 sin darme cuenta de que al resetear se salta a la ROM 0. He hecho los cambios en la carpeta firmware del repositorio. A diferencia de la sugerencia de McLeod, en lugar de copiar los 4 bancos repetidos sólo hago la copia en la ROM 0. El problema es que copiar un banco es costoso en términos de tiempo, ya que se copia de SPI Flash a RAM. Esto sería en el caso donde se bloquee la paginación (ROM de 48K o cartuchos). Hay casos por ejemplo donde se quiere tener paginación y una única ROM de 48K, los típicos juegos que se cargan usando RANDOMIZE USR 0. En estos casos y en el de ROMs de 32K (+2 y 128K) se usaría replicación de bancos.

[Quest]

Ufff Antonio... yo no lo veo... pero es mi opinión, muy personal, claro. Puede que sea deformación profesional, no sé. Estuve trabajando en una empresa donde fui responsable de usabilidad de interfaces....

Por un lado, me ha costado 3 veces leer el post para entender el funcionamiento (de todos modos, esto es seguramente culpa de mi cabezota )

Por otro lado, no veo el por qué limitarse a un tipo muy concreto de joystick, que probablemente la mayoría de la gente no tiene, y por otro, hacerle entender al usuario cómo ha de hacerlo, (y a ciegas...) y cómo asegurarse de que lo ha hecho bien. Va a tener que tener además una chuleta impresa al lado (yo al menos de memoria me veo incapaz).

Un spectrum (salvo que sea un Vega ) y en concreto el ZX-UNO yo no lo veo para usarse sin teclado la mayoría del tiempo. Y aunque así fuera, veo mucho más intuitivo, configurarlo una primera vez en BIOS con el teclado a tu gusto y luego ya usarlo con el joystick si quieres.

No lo vería mal, no obstante, como una opción secundaria para el caso puntual de los usuarios que tengan ese tipo de joystick/pad y que quieran (y se vean capaces) de configurar al vuelo el joy sin resetear. Por otro lado, eso también tiene el problema de que cualquier pulsación por error o descuido del botón secundario mientras estás jugando, junto a otro botón, desconfigurará el mando, y por tanto, probablemente perderás 1 vida de tu personaje

----

Con respecto a lo de las ROMs, justo cuando has actualizado estaba pensando en eso, en que le cuesta el cuádruple de tiempo arrancar al ZX-UNO cuando lo hace como un +3 que como un 48k, por el uso de 4 bancos en vez de 1. Desde luego, lo de la tardanza en el arranque era uno de los motivos por los que suelo usar ROMs más pequeñas para arrancar, en vez de la del +3e. Sería interesante reducir siempre los tiempos al mínimo. Quizá si se usara algún chivato, flag, zona de recuerdo de en qué banco se está, no se...

[antoniovillena]

Comprendo que no parece muy "usable" así de primeras, pero es la única forma de mapear un teclado completo. El problema es que McLeod no tiene espacio suficiente (tendría que quitar muchas cosas del core) para implementar OSD. Mi idea es tenerlo como opción en la BIOS; estarían las 3 ó 4 opciones típicas y esta sería la última, algo como "Seleccionable Botón 2". Pero vamos que ya lo he propuesto varias veces y en ninguna he tenido éxito.

Las posiciones a memorizar serían SJS1 (arriba izquierda), SJS2 (arriba derecha), Disparo (OPAQ Espacio) y sólo botón secundario (Kempston). Las demás posiciones sería para tenerlas serigrafiadas en algún lado, aunque es posible llegar a ellas pensando un rato. El truco es pensar que la segunda fila QWERTYUIOP es la central y para acceder a las 3 primeras filas usas un movimiento natural de palanca. La cuarta fila se mapea con movimientos "antinaturales" arriba y abajo.

Una pulsación accidental del botón secundario se arregla con otra pulsación del botón secundario. Por ejemplo si estás en OPAQ Espacio y de repente el joystick deja de funcionar, sólo tienes que pulsar los 2 botones a la vez para volver a la configuración OPAQ Espacio. Ya sé que no es algo que vaya a usar mucha gente, pero como opción para usuarios avanzados no estaría mal.

-- Actualizado 13 Jun 2015, 23:50 --

Otra opción es desproteger los puertos que configuran el mapeado del joystick para acceder a ellos fuera de la BIOS. Se podría hacer una rutina NMI que muestre un pequeño menú en el que se pueda navegar con el joystick (sin botón secundario) para hacer la selección. Pero esto requiere parchear ROMs.

-- Actualizado 14 Jun 2015, 00:04 --

Lo de usar un botón secundario para conmutar tampoco es tan descabellado. De hecho el propio Vega hace algo parecido. El dispositivo tiene 12 botones (11 normales y 1 secundario). Para los juegos que necesiten pulsar más de 11 teclas se usa el botón secundario para conmutar entre 2 mapeos distintos y así acceder hasta a 22 teclas del spectrum. Como curiosidad las 12 teclas son la cruceta (4 teclas), las teclas F, S, 1 y 2 y otros 4 botoncitos pequeños debajo de estas teclas. En el prototipo inicial estos 4 botoncitos no estaban y si Chris Smith ha tenido que convencer a su equipo de que había que ponerlas es porque no es tan fácil consolizar un gomas.

[mcleod_ideafix]

El core TEST 16 está bastante avanzado, y como ya se adelantó, presenta nuevas características. Las presento en este pequeño video, que sirve también como tutorial para los nuevos comandos ESXDOS que acompañan a estas nuevas características.


El software que se menciona en el video lo teneis dentro de la carpeta "software" del repositorio. En concreto, teneis que copiar los comandos JOYCONF, ZXUNOCFG y KEYMAP al directorio BIN de vuestra tarjeta SD, y dentro del directorio del core test16, vereis un directorio llamado KEYMAPS con dos ficheros: ES y US. Cread un directorio KEYMAPS dentro de /SYS en la tarjeta SD, y poned ahí esos dos ficheros. Así podreis cambiar de mapa de teclado.

Las configuraciones de teclado que creó Antonio, Hark0, Mejias3D, etc, pueden recrearse haciendo un mapa: se puede cambiar de mapa de teclado "on the fly" sin necesidad de crear un core nuevo para ello. Más detalles en el video.

Me falta por explicar los detalles de cómo crear nuevos mapas, tanto para crear un mapa "por defecto" para cuando se arranca el core (o sea, un mapa prefijado que se sintetiza) y cómo crear un fichero de mapa. Para los conocedores del lenguaje C, echad un vistazo a los dos ficheros en C que hay en el core test16: genkeymap_es.c y genkeymap_us.c que igual con eso solamente os haceis una idea. Para el resto del mundo mundial, publicaré los detalles en la wiki técnica.

Ah! Un programa que no se menciona en el video es "testkeys". No es un comando ESXDOS como los otros, sino un fichero TAP normal, para cargar desde ESXDOS con el NMI. Es una pequeña adaptación de otro que escribí hace años y que pubiqué aquí mismo en el foro hace unos días, para comprobar el teclado. Esta nueva versión incorpora información sobre la tecla del teclado PS/2 pulsada. Nos da: su scancode en hexadecimal (según el scancode set 2), si está pulsada o soltada (aparecerá RLS si está soltada) y si es un código normal o extendido (aparecerá EXT). Por ejemplo, la tecla Intro del bloque alfanumérico tiene como scancode el 5A. La tecla Intro del bloque numérico es 5A, extendida. Con esta utilidad podeis ver los scancodes de cualquier tecla de vuestro teclado PS/2, incluyendo las teclas multimedia. Muy útil para cuando querais crear vuestros propios mapas.

[Quest]

Gran actualización

Ya he grabado el nuevo core y probado todo lo comentado en el vídeo. Todo va perfectamente. Un gustazo

Sólo 1 detalle, sin importancia: en la ayuda de joyconf -h , dependiendo de la rom con la que arranques (Supongo que por el tema de la localización) algunos caracteres como los corchetes [] no salen, y a cambio salen la interrogante ? y la admiración si no recuerdo mal. Vamos, lo dicho, ninguna importancia A veces también ocurre (no se por qué, me ha pasado 2 de 10 veces o así) que la ayuda no cabe entera, porque el texto empieza muy atrás en la primera línea, y pide "¿SIGO?" al final.

Por otro lado, el tema del teclado, genial lo de los mapeos. Poderse hacer uno personalizado es absolutamente sublime

Imagino que el tema de la comunicación bidireccional todavía esta por hacer, dado que he probado con mis teclados conflictivos y todavía no hay respuesta.

Gracias por los avances Ya tengo ganas de ir viendo algunos añadidos a la BIOS con las nuevas funcionalidades. Esto ya depende de Antonio.

Por cierto, ahora que tenemos la info de la versión del core, quizá deba aparecer en la BIOS a modo de información para saber en qué core estamos de forma rápida. Y quizá se pueda añadir esa info al machine.tap para que al hacer upgrade machine, salga en la cabecera y se pueda comparar la versión actual y la versión a la que vayamos a actualizar.

[mcleod_ideafix]

Sólo 1 detalle, sin importancia: en la ayuda de joyconf -h , dependiendo de la rom con la que arranques (Supongo que por el tema de la localización) algunos caracteres como los corchetes [] no salen

En las ROMs españolas cambiaron el código ASCII y algunos caracteres se los "comieron", por lo que no existen. La verdad es que no uso ROMs españolas con el Spectrum, y tanto esto como otros problemas son fruto precisamente de la puñetera localización.

A veces también ocurre (no se por qué, me ha pasado 2 de 10 veces o así) que la ayuda no cabe entera, porque el texto empieza muy atrás en la primera línea, y pide "¿SIGO?" al final.

La ayuda se muestra usando la misma rutina PRINT que se usa en el BASIC, por lo que si la última cosa que se imprimió dejó el cursor de impresión, pongamos, a mitad de pantalla, pues a partir de ahí se imprimirá la ayuda. Basta con pulsar ENTER una vez para borrar la pantalla antes de ejecutar .joyconf -h y que salga desde la primera línea.

Imagino que el tema de la comunicación bidireccional todavía esta por hacer, dado que he probado con mis teclados conflictivos y todavía no hay respuesta.

Si te has descargado el core hoy domingo, te comento que sí está hecho, lo que pasa es que no hay ninguna utilidad escrita que haga uso de ella. Si quieres enviar comandos, puedes usar este programa en BASIC:

Código: Seleccionar todo

10 OUT 64571,4
20 OUT 64827,237: PAUSE 1: OUT 64827,2

Los comandos se envían mediante el puerto 64827. Antes hay que poner un 4 en el puerto 64571 para indicar que vamos a usar el registro 4 del ZX-Uno, que en lectura te da el último scancode pulsado o soltado, y en escritura permite enviar un comando al teclado. Para dar tiempo al teclado a que los procese, pongo un PAUSE 1 en medio. En este ejemplo en particular estoy enviando el comando ED para cambiar el estado de los leds. Concretamente, este programita enciende el led de Num Lock.

Si quieres enviar un reset (comando 255 en decimal) espera una pausa más larga, pongamos PAUSE 50, ya que se tarda más en procesar este comando.

Por cierto, ahora que tenemos la info de la versión del core, quizá deba aparecer en la BIOS a modo de información para saber en qué core estamos de forma rápida. Y quizá se pueda añadir esa info al machine.tap para que al hacer upgrade machine, salga en la cabecera y se pueda comparar la versión actual y la versión a la que vayamos a actualizar.

Lo primero lo intenté implementar por mi cuenta, pero no sé cómo está escrita la BIOS, que toque donde toque, me la cargo. Lo segundo no sé si habrá forma sencilla de implementarlo, dado que la información del core está embebida dentro del propio bitfile y no creo que sea sencillo extraerla de allí para ponerla como campo de cabecera. Igual puedo dejar en el código fuente del core esa información aparte en un fichero de texto para que tanto el entorno de Xilinx como las utilidades de Antonio lean ese archivo de forma independiente.

[Quest]

Si te has descargado el core hoy domingo, te comento que sí está hecho, lo que pasa es que no hay ninguna utilidad escrita que haga uso de ella. Si quieres enviar comandos, puedes usar este programa en BASIC:

Código: Seleccionar todo

10 OUT 64571,4
20 OUT 64827,237: PAUSE 1: OUT 64827,2

Los comandos se envían mediante el puerto 64827. Antes hay que poner un 4 en el puerto 64571 para indicar que vamos a usar el registro 4 del ZX-Uno, que en lectura te da el último scancode pulsado o soltado, y en escritura permite enviar un comando al teclado. Para dar tiempo al teclado a que los procese, pongo un PAUSE 1 en medio. En este ejemplo en particular estoy enviando el comando ED para cambiar el estado de los leds. Concretamente, este programita enciende el led de Num Lock.

¡Siiii!

Acabo de hacer la prueba. Evidentemente como los teclados conflictivos no funcionan, no podia teclear el código BASIC, pero sí lo he tecleado con un teclado funcional, pero poniendole delante de todo un pause 300 para que me diera tiempo a cambiar de teclado mientras tanto.

¡¡FUNCIONA!!

Ambos teclados conflictivos, como era de esperar, se inicializan perfectamente una vez que les envías cualquier cosa (de hecho, como analicé no hace mucho, bastaba con amagar enviarles algo para que ocurriera).

Calculo que cualquier teclado híbrido USB-PS/2 va a funcionar sin problema ahora.

Sólo falta que al arrancar el ZX-UNO se envíe automáticamente al puerto PS/2 un comando cualquiera, por ejemplo el de reset. Imagino que se podrá hacer desde la propia BIOS que muestra la pantalla del logo.

[mcleod_ideafix]

Sólo falta que al arrancar el ZX-UNO se envíe automáticamente al puerto PS/2 un comando cualquiera, por ejemplo el de reset. Imagino que se podrá hacer desde la propia BIOS que muestra la pantalla del logo.

Si, esa es otra de las cosas que Antonio tendrá que poner en la BIOS (si quiere, claro, que pa eso es su criaturita). Ojalá el ESXDOS tuviera algún modo de autoejecutar un fichero cuando se arranca, pero si lo tiene, no sé cómo se hace. Sé que carga unos .SYS al principio pero no sé si puedo añadir mis propios SYS con las cosas que quiero. Si eso es así, tenemos una forma de personalizar el sistema en el arranque sin necesidad de hacer cambios a la BIOS. Investigaré el asunto.