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