Ayuda con script de linux

[tactica]

Pues por curiosidad he mirado la tarjeta que tengo con juegos desde el PC y no tiene un nivel sino dos, uno con cada letra y luego dentro cada juego en un subdirectorio propio. O sea que supongo que algún "truco" usará el código.

O más bien el SD2IEC "traduce" de FAT al formato del C64, porque está claro que el C64 no podría manejar directamente un sistema de archivos de 4GB.

[javu61]

Por lo que he visto, lo que hace el SD2IEC es un truco habitual, en el C64 se lanza el comando

OPEN1,8,15,"CD/NOMDIR/":CLOSE1

Y esto activa el directorio NOMDIR de la tarjeta, a partir de entonces los comandos que se lancen lo hacen sobre ese directorio. Es la ventaja de usar un microcontrolador, que puede hacer mas cosas de las que soportan los sistemas originales. Este comando es ficticio, pues no hace mas que abrir un fichero y cerrarlo inmediatamente, no afecta a nada.

Es similar a los sistemas de conmutación de bancos de memoria RAM, aunque en estos se hace por hard, cuando se lee una dirección de memoria o se lanza la lectura de un puerto determinado, se conmuta el banco de memoria. Así un Z80 que solo soporta 64Kb puede manejar los 128Kb del Spectrum o del CPC.

[Querubin]

Según arananet ese mismo comando lo hace con el IECATA.

Cambiarse de directorio:

OPEN1,10,15,”CD:midirectorio”:CLOSE1

Formatear el disco duro:

OPEN1,10,15,”N”:CLOSE1

Entonces ¿la diferencia radica en el sistema de archivos del disco?¿O en la programación del microcontrolador?.

Voy a estudiar la transferencia de archivos PC-C64 por si me facilitara la faena.

[overCLK]

Hola querubin, cuando tenga algo de tiempo le echo un vistazo, que me empieza a picar la curiosidad.

En realidad supongo que esto que dices se debería poder hacer, porque si hay comandos para cambiar de directorio en la implementación del C64, también debería poder haberlos en la del software para PC. Solo lo vi un poco por encima, pero lo que falta en el github de arananet es el código que implementa la capa de acceso al disco duro en crudo. Ese código creo recordar que se puede compilar o bien para el microcontrolador o para linux y junto con el subir.c que es el frontend que ha implementado arananet permite interactuar con el disco duro a bajo nivel.

Mi impresión es que para hacer lo que quieres, habría que mejorar ese subir.c (o la capa de bajo nivel) para que aceptase y procesase ficheros con su directorio y los crease en el disco con los comandos pertinentes teniendo en cuenta las limitaciones que pueda haber (número de directorios, longitud de los paths, ...)

Lo dicho, lo miraré cuando tenga algo de tiempo, pero yo creo que habrá al menos que implementar otro frontend, y de paso hacer una versión gráfica para mayor facilidad de uso.

[Querubin]

La gui la espero con impaciencia. Me parece esencial. Sin ella, gestionar los archivos sería muy tedioso a golpe de comando.

Lo de pedir ayuda con el script es por ver si podía adelantar metiendo el romset completo que no veo manera de hacerlo sin que sea archivo por archivo.

Este interfaz es una gran idea. Lástima que no haya tenido interés prácticamente hasta hoy. Si no, ya se habrían hecho muchas mejoras y sería la leche.

[overCLK]

Hola,

he empezado a echarle un ojo a esto, y la verdad es que para empezar creo que no es necesario que estas utilidades accedan a un disco duro de verdad, al menos desde el lado del PC. Significa que tal y como está programado puede abrir tanto el disco duro directamente (como en los ejemplos cuando se le pasa /dev/sdb) o un fichero físico que luego podemos volcar en crudo al disco duro.

También veo que entre los fuentes hay un unix.c que parece un frontend bastante más completo que ese "subir" que se usa en el script. No lo he compilado aún porque no tengo un linux aquí, sólo estoy mirando los fuentes, pero a ver si puedes hacer esta prueba de concepto, una vez hayas compilado ese unix.c, digamos que a un fichero unix que puedes colocar por ejemplo en /var/tmp para las pruebas:

• Generamos un fichero vacío para probar, digamos de 10Mb:

dd if=/dev/zero of=c64disk.img bs=1024 count=10240

• Con esa utilidad unix que hemos compilado, lo formateamos, creo que se podría hacer tal que así, ya que admite comandos por la entrada estándar.

echo "format" |  /var/tmp/unix c64disk.img

• Creamos un directorio

echo "mkdir testdir" | /var/tmp/unix c64disk.img

• Cambiamos a ese directorio

echo "cd testdir" | /var/tmp/unix c64disk.mig

• Copiamos un fichero a ese directorio

echo "import <ficheroprueba> <nombredestino>" | /var/tmp/unix c64disk.img

Una vez hecho esto, deberíamos tener una imagen válida para meter en un disco duro (aunque sea de más de 10Mb, el resto quedará sin usar, pero es solo una prueba). Ahora podemos volcar esta imagen a un disco de verdad, suponiendo que está en /dev/sdb, con algo así:

dd if=c64disk.img of=/dev/sdb

Esto no debería hacer ningún daño al disco, más allá de corromper todos sus datos, pero vamos, nada irreversible.

Ya me contarás si esto funciona o que problemas te encuentras y si luego puedes leer el disco desde el C64.

Si esto funciona, es una base para poder hacer un script más potente que copie imágenes complejas y generar las imágenes con sus directorios y todo (eso sí, viendo los fuentes parece que solo se soporta un nivel de directorios) , y se podría hacer un frontend en cualquier lenguaje, ya que me parece que una vez que tenemos acceso al descriptor de fichero, sólo se trata de escribir normalmente sobre el. Toda la parte "esotérica" de los fuentes con comandos de bajo nivel es para la controladora, no para el software de PC.

De todos modos, lo que creo que estaría bien es implementar un sistema de ficheros FUSE. FUSE es una funcionalidad de Linux que permite implementar sistemas de ficheros en espacio de usuario: el kernel proporciona una especie de pasarela para que un programa de usuario implemente el sistema de ficheros y se pueda acceder a el desde un directorio determinado. Por ejemplo ntfs-3g es un sistema de ficheros FUSE si no me equivoco.

¿Ventajas? Ya no necesitamos un frontend, porque los ficheros los vemos directamente de forma natural, como si hubieramos montado un CD o un floppy, y cualquier visualizador de ficheros nos sirve para copiar a el o desde el de forma natural. La misma implementación puede hace las transformaciones necesarias a la hora de copiar los ficheros (truncar nombres demasiado largos, impedir crear directorios de más de los niveles que se soporten,...). Tan solo tendríamos que hacer algo como:

fuseiec64 /dev/sdb /mnt

Y podríamos acceder ya en /mnt a los ficheros y directorios del disco IECATA con los comandos normales del sistema operativo.

¿Desventajas? Sólo funcionaría en Linux o a lo sumo en OSX (que también soporta FUSE, pero como todo lo de Apple, será un poco diferente, y probablemente tengamos que firmar el binario como desarrollador autorizado para no tener que desactivar todas esas protecciones bonitas que trae.

A mi ahora mismo me llama más lo de FUSE, más que nada porque nunca he hecho nada de eso, y parece una solución elegante. De hecho lo pensé en su día para los DSK, cuando estaba intentando mejorar las dsktools con un frontend gráfico, proyecto que tengo algo abandonado.

A ver si por la tarde tengo un rato y compilo las utilidades en un linux para probar esto yo mismo.

Ya me contarás.

[Querubin]

Que fiera...

El script iecata.sh abre ese mini frontend donde puedes formatear, crear directorios, ver contenido, subir, etc...

De todos modos. No crees que sería más conveniente ir a por la gui en güindous?

[overCLK]

Que fiera...

El script iecata.sh abre ese mini frontend donde puedes formatear, crear directorios, ver contenido, subir, etc...

De todos modos. No crees que sería más conveniente ir a por la gui en güindous?

No tengo ningún script iecata.sh en el paquete de software que me bajé. Igual pusiste varios y tengo otra versión, no sé. De todos modos, si usa ese ejecutable 'unix', demuestra que se puede hacer un script que ejecute todas las operaciones necesarias y o bien grabe a un fichero de imagen o al disco físico directamente. Por otro lado, he echado un vistazo al código y me parece que si soporta jerarquías de directorios de varios niveles.


Sobre lo de la GUI en windows, a ver, yo no soy mucho de Windows (nada en realidad), ni tengo conocimientos para desarrollar nada ahí a bajo nivel. Podríamos hacer un programa con interfaz gráfica para generar la imagen que luego tendrías que volcar con algo externo en el disco físico. Es decir, este programa generaría un fichero con la imagen, pero como yo lo haría en Java para que fuera multiplataforma y porque no soy mucho de "güindous" ni lo uso habitualmente, pues no podríamos acceder a ese bajo nivel al disco. Luego tendrías que pasar esa imagen al disco con alguna herramienta equivalente al 'dd' de unix, supongo que cosas como rawrite o winimage (¿existe eso?) podrían valer.

Si lo que quieres es un programa que haga todo el proceso en windows incluyendo la grabación de la imagen al disco, pues tendrás que buscar otros colaboradores, me temo. Yo no tengo esos conocimientos y por desgracia tampoco la inquietud para aprender.

Entiendo que para un usuario de Windows sea un coñazo tener que irse a un linux para generar la imagen, y es verdad que la opción FUSE deja a los usuarios de Windows fuera, pero por otro lado Linux es gratuito y cualquiera lo puede instalar en casi cualquier ordenador, cosa que no se cumple para Windows.

Harías bien en abandonar el lado oscuro.

EDITO para comentar que en realidad hay un programa iecata que el Makefile genera a partir del unix.c. Así que el comando sería "iecata" y no "unix".

[Querubin]

Uso OSX hace años, pero nada de terminal. Lo de güindous era por popularidad. Y porque de tener que usarlo para según que cosas no te salvas.

Yo me adapto a lo que haga falta. Pero si no se puede hacer una gui para gestión másiva de ficheros arrastrando y pudiendo subirlos de manera transparente para que complicarse. Una vez que te adaptas al funcionamiento de los scripts lo haces con ellos. Eso si, añadir la opción de copiar directorios y subdirectorios sería "la mejora".

[overCLK]

Uso OSX hace años, pero nada de terminal. Lo de güindous era por popularidad. Y porque de tener que usarlo para según que cosas no te salvas.

Pero tampoco tenemos por qué apoyar esa tendencia, ¿verdad?

Yo me adapto a lo que haga falta. Pero si no se puede hacer una gui para gestión másiva de ficheros arrastrando y pudiendo subirlos de manera transparente para que complicarse. Una vez que te adaptas al funcionamiento de los scripts lo haces con ellos. Eso si, añadir la opción de copiar directorios y subdirectorios sería "la mejora".

Yo esto lo hago por diversión y para aprender. No se trata de complicarse o no. Con los scripts se puede hacer eso que quieres de crear la misma estructura de directorio en el destino, pero invocando al ejecutable "iecata" y no el "subir", que solo permite copiar ficheros, y haciendo comprobaciones de que los directorios y nombres de ficheros no sobrepasan los 16 caracteres para hacerlo un poco robusto.

He estado echando un ojo a la implementación y no sé si el sistema de ficheros está diseñado desde cero o no. No se parece al de CP/M, que es bastante sencillo en cuanto a la asignación de bloques.
A bajo nivel tiene un superbloque de 512 bytes donde guarda una especie de signature de la versión del sistema de ficheros (algo como "adfs 1.0") y un puntero a la posición de un bloque de 512 bytes donde guarda los punteros a bloques libres. El último puntero de este bloque apunta siempre al siguiente bloque con punteros a bloques libres (menos el último bloque de punteros, cuyo último elemento apuntará a cero).
Lo que me ha llamado la atención es que estos bloques de punteros no están en posiciones fijas: cuando los punteros de un bloque se han utilizado completamente (y va poniendo a cero los punteros del bloque) lo reutiliza para datos. La forma de volver a crear bloques de punteros es cuando se libera un bloque cualquiera y el bloque de punteros actual ya no tiene espacio libre para acomodar el bloque liberado, entonces este bloque se convierte a su vez en el bloque de punteros libres, donde el último elemento apunta al bloque actual que ya está lleno y se actualiza el superbloque con el puntero al elemento anterior. De este modo, los bloques de elementos libres van cambiando de posición según se va escribiendo y borrando del disco.