Página 2 de 2

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 9:59 am
por zup
La tarjeta se ha volcado por completo, está completamente vacía (todo a cero, fue víctima de un dd). El problema es que los discos físicos y las tarjetas rara vez son de una capacidad exacta. Ejemplos:

Código: Seleccionar todo

Tarjeta:             Bloques:   Capacidad:
--------             --------   ----------
SanDisk 64 Mb          121856   59.5 Mb
Dane-Elec 512 Mb      1000448   488.5 Mb
SanDisk 2 Gb          3862528   1.9 Gb
(sin marca) 2Gb       3911680   1.9 Gb
SanDisk 8 Gb         15523840   7.4 Gb
Samsung Evo 16Gb     31291392   14.9 Gb
El número de bloques lo he cogido haciendo un fdisk -l desde Linux.

No sé si es porque para los de marketing 1Mb=1000000 bytes o porque las tarjetas SD reservan parte de la capacidad como "area protegida" (mira esta sección del artículo en la wikipedia, pero en todas mis tarjetas la capacidad disponible no es exactamente una potencia de 2.

(Acabo de comprobarlo con una tarjeta MMC y algunas tarjetas CF. Si bien el número de bloques sigue sin ser exactamente potencia de 2, las capacidades son más parecidas a las teóricas)

Imagino que la solución pasa por utilizar un tipo de fichero que guarde la geometría del disco (número de bloques, cilindros, cabezas, sectores) y si lo necesitas, validar el tamaño contra la información almacenada en el fichero. No he logrado encontrar las descripciones, pero imagino que los .chd de MAME y los .hdf de ZX Spin pueden dar el pego.

EDITO: Según este documento, un fichero .hdf NO almacena la geometría del disco. Se puede calcular el número de bloques sabiendo la longitud del fichero, pero eso es todo lo que se le puede sacar.

También he de decir que al sacar la imagen la tarjeta estaba sobreescrita con ceros. Estaba haciendo experimentos con la geometría de disco según interfaces, así que no intenté leer la imagen más allá de hacer un CAT TAB con el +3e. ¿Qué crees que pasaría con ese número "raro" de bloques? ¿la trataría como una tarjeta de 256 megas o como una de 512 megas y la leería mal?

Mis pruebas con ZX-UNO mostraban que la geometría era detectada "correctamente" (igual a un ZX-UNO real, pero no tiene nada que ver con lo que detecta Linux ni un +3e con DivIDE). Si quieres particiono, formateo y le meto los ficheros del ZX-UNO a la tarjeta y repito las pruebas.

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 11:44 am
por chernandezba
Pufff entiendo que la mala práctica de los de marketing también ha llegado a las tarjetas SD :oops:
Esto pensaba que sólo sucedía con los discos duros...
Bueno realmente mi código de gestión de mmc está basado en eso, en tarjetas mmc. Las SD no son más que una evolución del MMC. Mi restricción de tamaños se aplica porque hay una serie de parámetros internos a nivel de protocolo que deben retornar el tamaño exacto de la tarjeta, y no hay manera de retornar algo así como 488.5 MB. Entiendo además que esa mala práctica de los amigos de marketing no se daba en tarjetas MMC.
Luego, aquí la solución fácil, en tu caso dado que veo que dominas Linux, es que hagas el volcado con dd (o un cat si me apuras), del device entero (tipo /dev/sda), pasando de herramientas externas. Y luego rellenar el espacio necesario con ceros, hasta llegar al siguiente valor admitido en ZEsarUX (en este caso 512 MB).
Simplemente puedes generar un archivo con ceros, usando dd, tantos bytes como te falten, y luego con un simple cat lo concatenas a tu volcado de imagen.
Luego internamente quien acceda a la tarjeta (sea esxdos, o sea +3e) ya tiene en el propio filesystem de la tarjeta el tamaño real del filesystem, que evitará que se vaya mas allá de esos 488.5 MB y llegue a leer la zona "no usada" con los ceros.

Prueba a ver con esto si te funciona

Saludos

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 11:55 am
por chernandezba
Agrego a lo anterior:
Me voy a poner una tarea en el TODO para que el emulador acepte esos tamaños de tarjetas extraños. Lo que hará en esos casos es, por una parte, avisar al usuario de que es un tamaño no habitual, y por otra, cuando acceda a dicha tarjeta, leerá "ceros" cuando vaya mas allá de su capacidad.
Y todos los cambios de escritura en la tarjeta se harán con el tamaño real de tarjeta, no escribiendo en ningún caso esos ceros de mas

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 2:39 pm
por zup
Creo que parte del problema es que esos "tamaños raros" en realidad son tamaños normales (o yo tengo muy mala suerte eligiendo tarjetas).

Por si las moscas, te voy a enviar una tarjeta en la que estaba trabajando. La tarjeta es una tarjeta "mixta" de 512 megas. Primero lleva 5 particiones IDEDOS (Juegos1, Juegos2, Utiles, Swap1 y Swap2) que están vacías (quería meter algún archivo para hacer pruebas, pero no he podido activar un +3 en ZEsarUX). Estas particiones se muestran como una partición extendida.

Detrás de eso, va una partición FAT16 normalita con los archivos de ESXDOS que usa el ZX-UNO. Probablemente este NO sea el caso típico en un Spectrum o un ZX-UNO, pero siendo algo más complejo te servirá para guarrear.

La tabla de particiones (versión CHS) es esta:

Código: Seleccionar todo

Disk /dev/mmcblk0: 488.5 MiB, 512229376 bytes, 1000448 sectors
Geometry: 4 heads, 16 sectors/track, 15632 cylinders
Units: cylinders of 64 * 512 = 32768 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4f37e263

Device         Boot Start   End Cylinders  Size Id Type
/dev/mmcblk0p1         33  1632      1601   50M  5 Extended
/dev/mmcblk0p2       1633 15616     13985  437M  6 FAT16
En versión LBA (solo bloques) es esta:

Código: Seleccionar todo

Disk /dev/mmcblk0: 488.5 MiB, 512229376 bytes, 1000448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x4f37e263

Device         Boot  Start    End Sectors  Size Id Type
/dev/mmcblk0p1        2048 104447  102400   50M  5 Extended
/dev/mmcblk0p2      104448 999423  894976  437M  6 FAT16
Fíjate que el total de bloques para la tarjetita son 1000448, como ya te he adelantado antes. Te recomendaría que hagas la prueba con un Linux y cualquier tarjeta SD que tengas a mano... ya verás como NO son las capacidades anunciadas.

En otro orden de cosas, es curioso que la emulación de DivIDE sea más "estricta" con el tamaño de las tarjetas que la de DivMMC. La de DivMMC protesta solo cuando el tamaño de tarjeta no es múltiplo de 256Kb, mientras que la de DivIDE protesta cuando el número no es "redondo" (128 megas, 256 megas, esas cosas).

EDITO: El enlace a la imagen de disco es el siguiente: https://mega.nz/#!LMNGRYyZ!g5EeM8PDOmiE ... 9VGbiBA_Ko

Es un fichero de unos 600Kb, pero descomprime a medio giga. Lo he probado y arranca en un +2A customizado (ROMs españolas del proyecto +3e 1.43, DivMMC deshabilitado para poder usar la tarjeta como disco), en un 48k con DivMMC (para acceso con NMI) y en el ZX-UNO.

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 8:20 pm
por zup
chernandezba escribió:Pufff entiendo que la mala práctica de los de marketing también ha llegado a las tarjetas SD :oops:
Esto pensaba que sólo sucedía con los discos duros...
Bueno realmente mi código de gestión de mmc está basado en eso, en tarjetas mmc. Las SD no son más que una evolución del MMC. Mi restricción de tamaños se aplica porque hay una serie de parámetros internos a nivel de protocolo que deben retornar el tamaño exacto de la tarjeta, y no hay manera de retornar algo así como 488.5 MB. Entiendo además que esa mala práctica de los amigos de marketing no se daba en tarjetas MMC.
Luego, aquí la solución fácil, en tu caso dado que veo que dominas Linux, es que hagas el volcado con dd (o un cat si me apuras), del device entero (tipo /dev/sda), pasando de herramientas externas. Y luego rellenar el espacio necesario con ceros, hasta llegar al siguiente valor admitido en ZEsarUX (en este caso 512 MB).
Simplemente puedes generar un archivo con ceros, usando dd, tantos bytes como te falten, y luego con un simple cat lo concatenas a tu volcado de imagen.
Luego internamente quien acceda a la tarjeta (sea esxdos, o sea +3e) ya tiene en el propio filesystem de la tarjeta el tamaño real del filesystem, que evitará que se vaya mas allá de esos 488.5 MB y llegue a leer la zona "no usada" con los ceros.

Prueba a ver con esto si te funciona

Saludos
Uuuuh... entiendo un poco lo de los parámetros internos, pero no termino de estar de acuerdo en lo de los tamaños exactos. Mi (única) tarjeta MMC de muestra (una MMC+ que venía con una cámara de fotos Canon) tiene también un número "raro" de bloques (62720 bloques, cuando 32 megas exactos serían 65536). Hay otra prueba curiosa que se puede hacer con Linux.

Si tienes un aparato con lector SD nativo (un portátil, una Raspberry Pi) se puede acceder a la controladora SD. Si vas a /sys/block/mmcblk0 hay una serie de ficheritos interesantes. Los que me han interesado son size (contiene el tamaño en bloques de la tarjeta), device/name (a veces contiene el modelo exacto de la tarjeta) y device/preferred_erase_size que contiene el tamaño de bloque que se usa al borrar/regrabar. Todo esto no se puede hacer con lectores de tarjetas, ya que aunque reportan el número de sectores "auténtico" esconden el resto de parámetros.

El hecho de que (de alguna manera) la controladora reporte el número "oficial" de bloques me hace pensar que el estándar está abierto a esas posibilidades.

Todo eso, hablando única y exclusivamente de MMC/SD.

Ahora es cuando vienen las curvas. El DivIDE. Sobre todo la parte IDE. El problema gordo es que el DivIDE (en teoría) permite conectar cualquier dispositivo IDE al Spectrum. Eso incluye tarjetas flash (mediante adaptadores), discos duros, CD-ROM (soportado por el firmware DEMFIR) y supongo que hasta unidades LS120 si es que tienes alguna.

Hacer que soporte el CD quizás sea una pérdida de tiempo, pero la clave está en el soporte para discos duros. Aquí es donde empiezan los tamaños raros, como 85 megas de un Western Digital Caviar WD210 o los 210 megas de un Conner CFS210 (he tenido ambos). Entiendo que la emulación de DivIDE debería estar abierta a todo tipo de tamaños, ya que tener un disco duro no era un caso tan raro.

Por cierto... me pregunto si alguien habrá hecho el experimento de conectar una LS-120 al DivIDE...

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mié Sep 21, 2016 10:56 pm
por chernandezba
Gracias por toda esta información :D
Le echaré un vistazo a ver si estas limitaciones que tengo de tamaño se pueden eliminar o no. Por lo que recuerdo, y sin revisar mi código, se debía básicamente a que tenían que ser múltiples / potencias de 2, lo típico... ;)

Saludos

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Lun Oct 03, 2016 4:25 pm
por zup
Otra cuestión relacionada con el divide y el MMC... ¿has pensado en cambiar la forma de leer/escribir ficheros?

Probablemente esté equivocado, ya que sólo he observado "desde fuera" el emulador. He estado haciendo experimentos para intentar crear particiones con el ZX-Uno (no sé si es posible, el cacharro real me hace cosas raras), y me mosqueaba que la máquina emulada diera parones cuando la máquina real no lo hace.

Lo que he observado:
- Según el consumo de memoria, cuando se abre un fichero .mmc ZEsarUX reserva memoria para TODO el fichero (y posiblemente lo lee completo en memoria).
- Cuando se modifica el fichero (creación de particiones, grabación de ficheros, etc), ZEsarUX escribe TODO el fichero a disco. No estoy seguro de si lo hace por cada escritura o espera un tiempo antes de volcarlo a disco. El problema lo detecté porque, aparte de que le costaba volver al BASIC tras crear particiones, en un momento dado ví que el fichero medía 0 bytes (se estaba escribiendo en ese mismo momento).

Este comportamiento, con las tarjetas de memoria que adjuntas (32 megas) no ralentiza mucho la emulación. Los problemas que veo son si el fichero .mmc está ubicado en un USB, tarjeta flash o SSD (muchas escrituras innecesarias) o si empleas tarjetas virtuales grandes (la mía era de 512 megas, una de varios gigas puede ser la leche).

Imagino que esto no es prioritario, y que requerirá repensarse cómo hacer lecturas y escrituras... ¿para la versión 5.x?

Re: Nueva version emulador ZEsarUX-4.1

Publicado: Mar Oct 04, 2016 12:10 am
por chernandezba
Es exactamente como dices :)
Se lee todo el archivo en memoria y las lecturas/escrituras se trabajan sobre esa RAM. Cuando hay una escritura se marca un flag a 1, y luego hay una tarea de flush que a cada segundo comprueba ese flag. Si han habido cambios, se vuelca toda la memoria a disco.
Se que no es todo lo eficiente que cabría esperar pero de momento lo dejaré así. No le veo mucho sentido tener tarjetas de varios GB (tarjetas emuladas con archivos de disco en este caso), pues en una de esas tarjetas te cabe todo WOS multiplicado por 100 :P
Es mas, a partir de tarjetas de 2 GB no funciona correctamente.

Saludos