Novedades acerca del ZX-Uno

[TallerSeverino]

Bueno, después de ordenar un poco la mesa de trabajo tras todo el soldar una foto en condiciones.
Es el test 12 con la prom2.mcs de Antonio, una maravilla la bios, un poco rápida, hay que estar atento, claro está, y aún no me he familiarizado con el entorno, pero en una tarjeda sdhc he seguido los pasos y cargado el "flunky", a mi en su tiempo me parecía un juego muy entretenido.


Es una maravilla el zx-uno, de nuevo mis felicitaciones.

[antoniovillena]

¿Estarán las nuevas placas para RM? Lo digo para recoger todo allí y poder soldar de una vez esto.

No. Están pedidos los componentes y han llegado unos pocos, pero las PCBs no están aún ni diseñadas. Una vez superfo me envíe los gerber tardarán un mes.

@TallerSeverino, he actualizado la BIOS a la versión 0.210. Lo nuevo que tiene es que puedes actualizar la máquina o la BIOS desde la propia BIOS. Antes ya había un método para actualizar la BIOS, ejecutando el archivo loadf.bat desde la ROM CargandoLeches.

Ahora no hace falta ni siquiera cargar una ROM, desde la propia BIOS se pueden cargar 3 tipos de archivos:

• ROMs y juegos de cartucho. Te metes en el menú ROMs de la BIOS y pulsas la letra N. Luego cargas uno de los 10 juegos que hay en firmware/roms, serían los archivos TAPs. También he subido los .rom originales en la misma carpeta.
• La propia BIOS. Esto es lo que hacíamos antes con loadf.bat. Ahora se hace desde el menu Upgrade/Upgrade BIOS de la BIOS y cargando el archivo firmware/roms/firmware.tap.
• La máquina. Esto incluye la configuración de la FPGA, la ROM del DivIDE, la BIOS y la tabla de ROMs, todo en un solo archivo llamado firmware/roms/machine.tap. Con esta opción (menu Upgrade/Upgrade machine) ya no necesitas el cable USB, puedes guardar el cable y desinstalarte el ISE WepPack.

Por supuesto todos los TAPs se pueden cargan en modo turbo con la utilidad CgLeches.exe que hay en firmware, tecleando CgLeches archivo.tap archivo.wav. Es muy recomendable cargar la máquina en modo turbo puesto que son 12 bloques de 16K cada uno y en modo estándar tardaría un montón.

Lo primero de todo, por supuesto, es cargar el archivo firmware/roms/prom.mcs en el ZX-Uno, espero que sea el último .mcs que carguéis.

[TallerSeverino]

@TallerSeverino, he actualizado la BIOS a la versión 0.210. Lo nuevo que tiene es que puedes actualizar la máquina o la BIOS desde la propia BIOS. Antes ya había un método para actualizar la BIOS, ejecutando el archivo loadf.bat desde la ROM CargandoLeches.

Ahora no hace falta ni siquiera cargar una ROM, desde la propia BIOS se pueden cargar 3 tipos de archivos:

• ROMs y juegos de cartucho. Te metes en el menú ROMs de la BIOS y pulsas la letra N. Luego cargas uno de los 10 juegos que hay en firmware/roms, serían los archivos TAPs. También he subido los .rom originales en la misma carpeta.
• La propia BIOS. Esto es lo que hacíamos antes con loadf.bat. Ahora se hace desde el menu Upgrade/Upgrade BIOS de la BIOS y cargando el archivo firmware/roms/firmware.tap.
• La máquina. Esto incluye la configuración de la FPGA, la ROM del DivIDE, la BIOS y la tabla de ROMs, todo en un solo archivo llamado firmware/roms/machine.tap. Con esta opción (menu Upgrade/Upgrade machine) ya no necesitas el cable USB, puedes guardar el cable y desinstalarte el ISE WepPack.

Por supuesto todos los TAPs se pueden cargan en modo turbo con la utilidad CgLeches.exe que hay en firmware, tecleando CgLeches archivo.tap archivo.wav. Es muy recomendable cargar la máquina en modo turbo puesto que son 12 bloques de 16K cada uno y en modo estándar tardaría un montón.

Lo primero de todo, por supuesto, es cargar el archivo firmware/roms/prom.mcs en el ZX-Uno, espero que sea el último .mcs que carguéis.

Me pongo a ello Antonio, gracias, ya que me estaba "peleando" con lo del cargador turbo, lo de concatenar roms al mcs y no lo había probado aún.
Estaba con tap2wave y cosas así por no entenderlo muy bien, al menos para los tests 11 y 12, a partir de tu prom2.mcs era todo más suave.

Decir que el menú de la bios es estupendo, no lo había comentado, pero es una bios muy completa, los familiarizados con las de pc como yo, son muy fáciles de manejar y guardar.

Para bajar el repositorio completo usando ubuntu se puede usar este comando en el terminal, te crea todo el árbol de subdirectorios:

Código: Seleccionar todo

 wget -r  --http-user=guest --http-password=zxuno http://www.atc.us.es/svn/zxuno/

[antoniovillena]

Los TAPs (y los TZXs) los cargo con Taper desde el portátil. Una vez te acostumbras a las cargas turbo es todo mucho mejor. Puedes crear cargas turbo también en formato TZX por si las quieres tener almacenadas. Yo las cargo en formato WAV con el programa que me lo abre por defecto, VLC. Como has podido comprobar no se necesitan muchas instrucciones para aprender a manejar la BIOS, tenía pensado subir un video pero no creo que haga falta.

Voy a hacer una pausa en el desarrollo de la BIOS, a no ser que aparezcan bugs. Lo que me falta sería:

• Los hardware tests del main.
• Check CRCs y Recovery en ROMs. El primero no es muy necesario, puesto que ya se te avisa cuando una ROM tiene el CRC incorrecto. El segundo (Recovery) sería para crear entradas nuevas basándonos en las ROMs que hay, o recuperar alguna que hayamos borrado (al usar Delete solo borramos la entrada).
• Boot. En este prototipo no tiene cabida. Es para la función multiboot del siguiente prototipo (Spartan 6 LX9), que permite arrancar distintas máquinas.
• Security. Para el tema passwords, es un poco chorra pero para igualar esa funcionalidad que tienen todas las BIOS.
• Carga mediante SDs formateadas en FAT16/FAT32 con LFN. Esto sería lo más útil, pero lo más complicado a la vez. Sería un método alternativo a la carga en cinta para subir ROMs y Upgradear.

Como ves, lo más importante ya está implementado. También me tengo que poner de acuerdo con McLeod para implementar un bloqueo de paginación MASTER (un modo de paginación especial que tiene el ZX-Uno) y del acceso a la SPI Flash. De esta forma aislamos la BIOS del resto de software, no siendo posible por ejemplo que un programa pueda corromper el contenido de la Flash (y tener que usar el cable USB para arreglarlo).

-- Actualizado 21 Abr 2014, 00:19 --

...una maravilla la bios, un poco rápida, hay que estar atento, claro está, y aún no me he familiarizado con el entorno...

Yo nunca me meto en la BIOS tras el arranque, sino que fuerzo un Master Reset con las teclas Ctrl+Alt+Backspace (si usas Ctrl y Alt derecho puedes hacer el combo con una sola mano) e inmediatamente pulso la tecla en cuestión (Esc ó F2). Lo ideal es dejar un retardo largo en el arranque y otro corto tras un Master Reset, pero no sé cómo distinguir una cosa de otra, puede que McLeod tenga alguna idea. El problema es que si alargo la espera (para pulsar la tecla) los Master resets se vuelven muy lentos.

[mcleod_ideafix]

[*]Carga mediante SDs formateadas en FAT16/FAT32 con LFN. Esto sería lo más útil, pero lo más complicado a la vez. Sería un método alternativo a la carga en cinta para subir ROMs y Upgradear.[/list]

Como ves, lo más importante ya está implementado. También me tengo que poner de acuerdo con McLeod para implementar un bloqueo de paginación MASTER (un modo de paginación especial que tiene el ZX-Uno) y del acceso a la SPI Flash. De esta forma aislamos la BIOS del resto de software, no siendo posible por ejemplo que un programa pueda corromper el contenido de la Flash (y tener que usar el cable USB para arreglarlo).

La razón por la que originalmente he dejado activado el acceso a la Flash desde el modo "usuario" es porque pensé que los updates de BIOS se harían usando el soporte de almacenamiento masivo de +3e o de DIVMMC. Es decir, que no se incluiría ningún sistema de ficheros en la BIOS precisamente por existir ya soporte de FAT/FAT32/CPM en los firmwares "normales", y que por tanto los programas de update serían programas que correrían sobre estos S.O.

Por supuesto, es mucha mejor opción la de desactivar el uso de la Flash desde algo que no sea la BIOS. Una forma muy cómoda de hacerlo es obligar a que el update esté en una tarjeta SD recién formateada, y como único fichero en ella. Así, el firmware sólo tiene que buscar el primer sector donde se encuentre el comienzo del update (quizás con alguna cadena mágica para identificarla rápidamente) y a partir de ahí, estarán todos los bloques seguidos, por no haber fragmentación.

Si te parece bien, lo que voy a implementar en el test13 es:
- Posibilidad para que la ROM interna pueda ser reescrita desde el modo de configuración. Así, la ROM interna del core lo que tendría es un pequeño stub para cargar desde una posición fija de la flash, la BIOS. Esa BIOS se copiará en lugar del stub y así, mientras el equipo tenga corriente, las siguientes veces que se resetee, lo hará a la BIOS.
- Bloqueo de los puertos de acceso a la flash desde los modos de usuario.

Yo nunca me meto en la BIOS tras el arranque, sino que fuerzo un Master Reset con las teclas Ctrl+Alt+Backspace (si usas Ctrl y Alt derecho puedes hacer el combo con una sola mano) e inmediatamente pulso la tecla en cuestión (Esc ó F2). Lo ideal es dejar un retardo largo en el arranque y otro corto tras un Master Reset, pero no sé cómo distinguir una cosa de otra, puede que McLeod tenga alguna idea

Con el cambio que voy a hacer, la diferencia entre un "power cycle" y un "master reset" es que el primero arranca el stub que a su vez carga y arranca la BIOS. El master reset arranca directamente la BIOS.
Pongamos que la ROM "stub" es de 16K y en los cuatro últimos bytes tiene la secuencia 01020304 grabada. La BIOS de Antonio es cargada, pero respetando estos cuatro últimos valores (o se ponen en otro sitio si ahí hay un juego de caracteres o algo). Al arrancar la BIOS se mira si la secuencia mágica existe. Si está, es que se ha arrancado desde un "power cycle", se hace la pausa, y se borra la secuencia (el área de ROM es escribible). Si no está, es que se ha arrancado desde un "master reset".

Otra forma, incluso más sencilla: el "master reset" es Ctrl-Alt-BkSpace. Las tecla BkSpace en el Spectrum es CAPS + 0. Por tanto, si en el arranque de la BIOS se detecta que las teclas CAPS SHIFT y 0 están pulsadas, muy probablemente sea porque el usuario ha hecho un "máster reset".

-- Actualizado 21 Abr 2014, 03:02 --

Voy a hacer una pausa en el desarrollo de la BIOS, a no ser que aparezcan bugs.

Pues no sé qué estaré haciendo mal, pero el PROM.MCS que hay en el directorio "firmware" no me acaba de funcionar bien. Arranco la BIOS, pulso F2 (en lugar de poner <Edit> y <Break> puedes poner <F2> y <Esc> digo yo, que son los nombres verdaderos de las teclas) y accedo a lo que es la configuración de la BIOS. Elijo arrancar la ROM del Spectrum 48K y activar DIVMMC. Grabo los cambios, y aquello mete algo de basurilla en pantalla y se acabó. Sólo puedo volver a hacer Ctrl-Alt-BkSpace y volver a la BIOS. La ROM que sí me ha arrancado es la del Deathchase 3D.

[antoniovillena]

Pues no sé qué estaré haciendo mal, pero el PROM.MCS que hay en el directorio "firmware" no me acaba de funcionar bien. Arranco la BIOS, pulso F2 (en lugar de poner <Edit> y <Break> puedes poner <F2> y <Esc> digo yo, que son los nombres verdaderos de las teclas) y accedo a lo que es la configuración de la BIOS. Elijo arrancar la ROM del Spectrum 48K y activar DIVMMC. Grabo los cambios, y aquello mete algo de basurilla en pantalla y se acabó. Sólo puedo volver a hacer Ctrl-Alt-BkSpace y volver a la BIOS. La ROM que sí me ha arrancado es la del Deathchase 3D.

No estás haciendo nada mal, a mí tampoco me funciona cuando está activado el DivMMC. Yo lo único que hago es poner a 1 el correspondiente bit del registro Master_Conf y llenar la mitad de la página 12 con la ROM del DivMMC (ESXMMC.BIN). Lo he revisado muchas veces y no doy con el error.

Con respecto a las teclas F2 y Esc soy consciente de la gran confusión que generan, pero esto no es un PC, es un spectrum con teclado de PC y pienso que lo suyo es empezar a acostumbrarse. No tiene sentido que en la BIOS se llame Esc y luego en la ROM del +2A por ejemplo te digan que presione Break dos veces. No obstante es mi opinión, y por lo visto sólo la mía, así que lo más probable es que acabe cambiándolo por Esc y F2 pese a no gustarme la idea.

Ah ya he alargado el tiempo de detección tras el arranque por el método de Shift+0 que me sugeriste, si puedes pruébalo, yo lo he probado en emulador y va bien.

-- Actualizado 21 Abr 2014, 03:30 --

El meollo del DivMMC está en este fragmento:

Código: Seleccionar todo

conti   di
        ld      a, %00100000    ; leo 3 bits
        ld      hl, keyiss
conti1  rr      (hl)
        adc     a, a
        dec     l
        jr      nc, conti1
        add     a, a
conti2  ld      (alto conti5+1), a
        ld      bc, zxuno_port+$100
        wreg    master_conf, 1
        and     $02
        jr      z, conti25
        wreg    master_mapper, 12
        ld      hl, $0295
        ld      de, $c000
        ld      a, $20
        call    alto rdflsh
conti25 ld      hl, active


Lo que hago es leer keyiss (para issue2/3), nmidiv (para desactivar el NMI) y divmap (para activar la paginación DivMMC) en los bits 3, 2 y 1 y lo guardo en una variable. Pongo Master_conf a 1 y Master_mapper a 12, cargando los 8K de ROM del DivMMC sólo en el caso de que divmap esté activo, y finalmente pongo el Master_conf con BOOTM a 0 y el resto de valores según la variable que he calculado antes.

[mcleod_ideafix]

No estás haciendo nada mal, a mí tampoco me funciona cuando está activado el DivMMC. Yo lo único que hago es poner a 1 el correspondiente bit del registro Master_Conf y llenar la mitad de la página 12 con la ROM del DivMMC (ESXMMC.BIN). Lo he revisado muchas veces y no doy con el error.

Si miras en TESTROM.ASM verás que también hay que borrar (poner a 0) el contenido de las páginas 16 a 23 inclusive. Probablemente baste con borrar las páginas 16 y 17 (los 32KB primeros). Esto es para que al arrancar ESXDOS fuerce a detectar la tarjeta SD y no coja la última configuración que hubiera en memoria, de otra tarjeta SD por ejemplo.

El meollo del DivMMC está en este fragmento....

Ah! Estupendo. Es lo que te iba a preguntar ahora. Lo miro a ver si veo algo extraño...

EDITO: no consigo descifrar el código. Ayudaría que hubiera más comentarios, y que las etiquetas no tuvieran nombres tan del estilo "label1", "label2", etc. Por otra parte, ¿qué significa "call alto loquesea"? Más concretamente, ¿qué significa la palabra "alto" ahí? .

La parte donde lee de la flash la ROM del ESXDOS y la carga en el banco 12 es aquí...

Código: Seleccionar todo

        wreg    master_mapper, 12
        ld      hl, $0295
        ld      de, $c000
        ld      a, $20
        call    alto rdflsh

¿Que significan esos parámetros en HL, DE y A antes del CALL?

[antoniovillena]

Sin haberlo comprobado espero que esto sirva:

Código: Seleccionar todo

        and     $02
        jr      z, conti25
        wreg    master_mapper, 12
        ld      hl, $0295
        ld      de, $c000
        ld      a, $20
        call    alto rdflsh
        ld      a, 16
conti24 ld      de, $c000 | master_mapper
        dec     b
        out     (c), e
        inc     b
        push    bc
        out     (c), a
        ld      bc, $3fff
        ld      hl, $c000
        ld      (hl), l
        ldir
        pop     bc
        inc     a
        cp      24
        jr      nz, conti24
conti25 ld      hl, active


Está actualizado en el repositorio, te bastaría con hacer Upgrade BIOS y cargar el archivo firmware/roms/firmware.tap (o ultracarga del mismo)

[mcleod_ideafix]

Está actualizado en el repositorio, te bastaría con hacer Upgrade BIOS y cargar el archivo firmware/roms/firmware.tap (o ultracarga del mismo)

No me funcionan bien las ultracargas con el sistema de audio que estoy usando en este momento para el ZX-Uno ¿Cómo puedo obtener el MCS para grabarlo desde Impact?

EDITO: el archivo por lotes generamcs.bat da errores por todos lados. make.bat lo mismo.

[antoniovillena]

Se me olvidaba, te paso los cambios que he hecho en el código Verilog.

• Línea 72 de memory.v por esta:
  

  Código: Seleccionar todo

        else if (addr==MASTERCONF && iow /*&& initial_boot_mode*/ )

  
  La idea es no bloquear el registro una vez se ponga a 0. Habrá que buscar otro mecanismo para bloquear dicho registro (por ejemplo usar otro bit del mismo al igual que hace el puerto 7ffd). Lo que me comentaste de hacer el bootloader escribible ya no vale. Valdría pero reescribiendo un montón de código. De todas formas la carga es bastante rápida, 20 ciclos por byte. Para que te hagas una idea, la comprobación CRC cuesta 59 ciclos/byte, por lo que si está activa dicha comprobación es cuatro veces más lento.
  
• En rom.v poner lo siguiente:
  

  Código: Seleccionar todo

     reg [7:0] mem[0:55];
   initial begin
      $readmemh ("bootloader_hex.txt", mem, 0);
   end

  
  
  El contenido de bootloader_hex.txt son los 56 bytes de bootloader.asm, no obstante lo pongo aquí si con el copy/paste te ahorras trabajo:
  

  Código: Seleccionar todo

  F3
01
3B
FD
F7
03
01
31
EF
BF
3E
02
F7
01
08
F7
03
00
F7
02
03
ED
79
11
61
E9
D5
56
D5
39
ED
61
ED
69
2B
ED
A2
04
BC
38
FA
05
ED
61
04
C3
EC
BF
E1
ED
A3
06
FE
ED
A3
E9


-- Actualizado 21 Abr 2014, 04:08 --

Está actualizado en el repositorio, te bastaría con hacer Upgrade BIOS y cargar el archivo firmware/roms/firmware.tap (o ultracarga del mismo)

No me funcionan bien las ultracargas con el sistema de audio que estoy usando en este momento para el ZX-Uno ¿Cómo puedo obtener el MCS para grabarlo desde Impact?

EDITO: el archivo por lotes generamcs.bat da errores por todos lados. make.bat lo mismo.

Las ultracargas debes generarlas con CgLeches.exe, no vale la aplicación html5 de la web porque he cambiado el formato. Respecto a make.bat:
-Debes compilar zx7b.c y GenRom.c
-Poner SjAsmPlus.exe en el directorio o path. http://sourceforge.net/projects/sjasmplus/
-Ídem con fcut. http://retrolandia.net/foro/showthread.php?tid=45
-CgLeches.exe sí que lo he incluído en el repositorio