ROM de la interfaz de disco de MicroPeripherals

Subforo oficial del Sinclair QL: realiza aquí las consultas relativas a tu QL.

Moderador: Sir Cilve Sinclair

Responder
Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

ROM de la interfaz de disco de MicroPeripherals

Mensaje por mcleod_ideafix » Dom Jul 25, 2010 6:31 am

Pues resulta que la única interfaz de disco que tengo es la "original" de Sinclair, la de MicroPeripherals. Tengo incluso una unidad de disco de color negro, pero está estropeada, así que uso una unidad Cumana que me funciona también en el +D y en el Disciple.

Cuando lo arranco, el mensaje de la ROM dice que es la versión 5.2S (la S por lo visto es de "Spanish"). Esta interfaz, como sabreis, se diferencia de otras en que en lugar de usar FLP para nombrar las unidades de disco, usa FDK.

Esto último no es problema, ya que lo primero que he hecho es hacer una copia de la ROM y modificarla para que en lugar de FDK use FLP. De esta forma puedo usar todo el software que viene preparado para disco...

... o eso creía, porque sorpresivamente, la orden LBYTES parece que no funciona. Lo he comprobado intentando cargar un bloque del disco directamente a memoria de pantalla: no se ha coscado. Antes de que alguien lo pregunte, lo digo: con la ROM original tampoco me funciona LBYTES.

¿Alguien sabe si esta interfaz tenía bugs de este tipo? En el manual que he encontrado sobre ella aparece una versión ligeramente distinta: trae 4 jumpers en lugar de los 5 que trae la mía, y hace mención a la versión 5.3 del firmware. La mía es la versión 5.2.

¿Se puede encontrar una versión más reciente de la ROM de esta interfaz por algún sitio?

Gracias!

PD: descarto que sea un fallo de la ROM principal (Minerva 1.98) o de la ROM de apoyo (Toolkit MKII) ya que estas mismas ROM's las uso en QemuLator y LBYTES funciona perfectamente ahí. La única diferencia entre QemuLator y mi QL real es la interfaz de disco, así que por eso concluyo que el fallo está ahí. Por otra parte, me es imposible probar un LBYTES desde un cartucho Microdrive, porque no tengo ninguno que ande correctamente (aunque seguiré buscando a ver si...)

AÑADO: no he conseguido usar ni uno solo de mis cartuchos de Microdrive, pero he probado otra cosa: desde el propio QL real he grabado una copia de la pantalla con:
SBYTES flp1_pantalla_bin,131072,32768

Al cargarla con LBYTES lo he hecho perfectamente.

Me llevo el disquete al QemuLator y lo pruebo: también funciona.

Copio el fichero (COPY FLP1_PANTALLA_BIN TO WIN2_PANTALLA_BIN) a la unidad WIN2_ que es un directorio compartido en Windows. La copia en WIN2_ carga con LBYTES en el emulador. El fichero según veo en el explorador de ficheros de Windows, ocupa exactamente 32768 bytes. No hay cabeceras ni historias raras.

Copio esta vez, desde la unidad WIN2_ hasta FLP1_ creando una copia del fichero con otro nombre, así: COPY WIN2_PANTALLA_BIN TO FLP1_P_BIN

Cargo P_BIN desde QemuLator con LBYTES y carga la pantalla.

Me llevo el disquete al QL real, intento cargar P_BIN y nada de nada.

Entonces pienso que tal vez SBYTES mete alguna información que COPY no mete, así que desde el emulador, me hago un pequeño programa que va reservando memoria con RESPR, carga con LBYTES a esa zona de memoria desde WIN2_ y luego hace SBYTES al disquete. Así con todos los bloques. Lo pruebo en el QL real y nada de nada.

En resumen: en el QL real sólo puedo hacer LBYTES de un bloque de memoria que haya guardado anteriormente, desde ese mismo QL, con SBYTES. Si copio un fichero binario al disquete usando el PC y un emulador, ese mismo fichero puedo cargarlo con LBYTES en el emulador, pero no en el QL real. Ambos, emulador y QL real, usan la misma ROM principal (Minerva 1.98 y la misma ROM de apoyo (Toolkit MKII). El QL real tiene una controladora MicroPeripherals, la "oficial" de Sinclair.

¿Qué está pasando? :( :?:
Web: ZX Projects | Twitter: @zxprojects

Zerover
Jack The Nipper
Mensajes: 112
Registrado: Mar Abr 08, 2008 9:00 am

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por Zerover » Dom Jul 25, 2010 12:43 pm

mcleod_ideafix escribió:¿Se puede encontrar una versión más reciente de la ROM de esta interfaz por algún sitio?


Tengo una imagen de la ROM 5.3E, dime a dónde te la mando.

Avatar de Usuario
badaman
Sabreman
Mensajes: 499
Registrado: Mar Ene 29, 2008 10:58 am
Contactar:

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por badaman » Dom Jul 25, 2010 2:06 pm

Zerover escribió:Tengo una imagen de la ROM 5.3E, dime a dónde te la mando.


Aquí tenéis la imagen de Zerover.
Sinclair QL, la respuesta profesional de los 80

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por mcleod_ideafix » Dom Jul 25, 2010 5:10 pm

¡Muchas gracias! Pero... ¡qué raro! Esta imagen es de 16K, y la EPROM que tengo en la interfaz de disco es de 8K... A ver... ¡un momento! ¡Anda! ¡Si es que este fichero tiene dos copias de la ROM idénticas! Entonces sí que me vale :) Lo pruebo y os cuento :)
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por mcleod_ideafix » Dom Jul 25, 2010 7:07 pm

Bueno, pues ya tengo la 5.3E (convenientemente parcheada para aceptar por defecto FLP en lugar de FDK) y esto no ha cambiado.
Pero creo que ya sé realmente lo que pasa aquí: la culpa, estoy seguro, es de QemuLator.

Lo estoy usando en modo "QL normal", y puedo leer y escribir en floppys. Hasta aquí todo correcto.

La diferencia está en lo que se guarda en la entrada de directorio (cabecera QDOS) cuando uso el QL real o cuando uso QemuLator: en el QL real, un archivo que he llamado trozo_bin, grabado con SBYTES, con una longitud de 6144 bytes (es pura casualidad, no trataba de meter una pantalla de Spectrum aquí :D ) tiene una cabecera como ésta:

Código: Seleccionar todo

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00001240  00 00 18 40 00 00 5F 01 64 00 00 00 00 00 00 09  ...@.._.d.......
00001250  74 72 6F 7A 6F 5F 62 69 6E 00 00 00 00 00 00 00  trozo_bin.......
00001260  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00001270  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Según la página 38 del QL Technical Guide, desde el offset 06 hasta el 0D, inclusive, se guarda información dependiente del tipo de fichero. El tipo de fichero, que se guarda en el offset 5, es 0 (que corresponde a "cualquier cosa"). La información referente a fecha de actualización y tal está toda a 0, ya que mi QL no tiene ningún tipo de reloj de tiempo real.

Cuando hago una copia desde WIN2_ hasta FLP1_ de un fichero con este mismo contenido (o si hago una copia desde FLP hasta WIN y luego de nuevo a FLP), y le pongo un nombre diferente, la cabecera del nuevo fichero es ésta:

Código: Seleccionar todo

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000012C0  00 00 18 40 00 00 00 00 00 00 00 00 00 00 00 09  ...^............
000012D0  74 72 77 69 6E 5F 62 69 6E 00 00 00 00 00 00 00  trwin_bin.......
000012E0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000012F0  00 00 00 00 5D 39 F7 A5 00 00 00 00 00 00 00 00  ....]9÷¥........

Desaparece la información dependiente del tipo, y aparece una información de fecha de actualización, que según el QL Technical Guide no está aún implementada, pero sí resrvada. Esta información, no obstante, no perjudica para nada lo que queremos hacer.

Me pongo a mirar el manual del QmuLator y me encuentro con esta información:
Manual del QemuLator escribió:QL files have a special piece of information associated with them, called the ‘QDOS file header’. The header stores such information as the file name and whether the file is an executable program.

Q-emuLator for Windows stores part of the header at the beginning of files. The header is present only when it is useful, ie. only if it contains non-default information.

The header has the following format:

Código: Seleccionar todo

OFFSET LENGTH(bytes)       CONTENT
0      18                  “]!QDOS File Header“
18     1                   0 (reserved)
19     1                   total length_of_header, in 16 bit words
20 length_of_header*2-20   QDOS INFO

The first 18 bytes are there to detect whether the header is present (ID string).

The headers Q-emuLator supports can be 30 bytes or 44 bytes long (the value of the corresponding byte at offset 19 is either 15 or 22). In the first case, there are 10 bytes with the values present in bytes 4 to 13 of the 64 bytes QDOS header. In the second case the same piece of information is followed by 14 bytes containing a microdrive sector header, useful for emulating microdrive protection schemes. Additional header information (file length, name, dates) is obtained
directly from the file through the host file system.

Some QL programs to translate between QDOS and Q-emuLator for Windows file formats are included in the Q-emuLator package.
The translation is transparently performed when you move files between QDOS floppy disks and Windows directories through Q-emuLator.


Según el manual, QemuLator debería haber detectado que hay información relevante en los bytes 6 al 13 de la cabecera, y debería haber creado una versión del fichero en Windows con la cabecera mostrada aquí, pero no lo hizo.
Así que con esa información, yo mismo creé una versión de mi "trozo_bin" en Windows, con la cabecera que se espera. Algo así:

Código: Seleccionar todo

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000240  5D 5D 21 51 44 4F 53 20 46 69 6C 65 20 48 65 61  ]]!QDOS File Hea
00000250  64 65 72 00 0F 00 5F 01 64 00 00 00 00 00        der..._.d.....

Y a continuación, el resto del fichero, es decir, los 6144 bytes. Pues bien, al copiar este fichero con COPY desde WIN a FLP, QemuLator HA IGNORADO SU PROPIA CABECERA, y ha copiado todo el archivo, cabecera incluida, a disquete.

Si pongo a mano la cabecera (esos bytes dependientes del tipo de fichero) en la entrada de directorio que corresponde a mi fichero copiado (trwin_bin), el QL no se cosca. Tengo que averiguar qué significan esos bytes, porque deben ser diferentes de un fichero a otro. UPDATE: en otros "trozos" de memoria que he copiado no aparecen! Esto empieza a ser raro.

En resumen: que tengo que cambiar de emulador :?

Por cierto: la única información que he encontrado referente a la estructura interna del sistema de ficheros en disco de QDOS es la mencionada página 38. No he encontrado nada más, así que no sé realmente qué hay en esos "datos dependientes del tipo de fichero" ni cómo se interpretan. ¿Dónde puedo encontrar una descripción más completa del sistema de ficheros?

¡Gracias!
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por mcleod_ideafix » Dom Jul 25, 2010 7:42 pm

Igual me basta con esto... A ver qué tal...
http://www.zen35309.zen.co.uk/misc/wxqt2.html
Web: ZX Projects | Twitter: @zxprojects

Avatar de Usuario
mcleod_ideafix
Johnny Jones
Mensajes: 3985
Registrado: Vie Sep 21, 2007 1:26 am
Ubicación: Jerez de la Frontera
Contactar:

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por mcleod_ideafix » Dom Jul 25, 2010 8:03 pm

También he encontrado esto otro. Parece ser que toda la información sobre dónde está cada archivo se guarda al principio del disquete (lo que sería una FATa en MSDOS):

Código: Seleccionar todo

2.   QDOS

      This is the disk format used on Floppy Disks used on the QL
      or any compatible machine.

      The vast majority of QL disk formats use sectors of 512
      bytes.  The only known exception is the Gold Card with ED
      disks where a sector size of 2048 bytes is used.

      The start of the first sector on the disk contains
      information regarding the layout of the remainder of the
      disk.

      Position  Length    Description
         0        4       Media identifier
                               QL5A for Double Density (DD) Disks
                               QL5B for High Density (HD) Disks
                               QL5B for Extended Density (ED) disks
         4        10      Medium Name  (space filled)
        14        2       Format Random Number
        16        4       Update count
        20        2       Free Sectors
        22        2       Good sectors
        24        2       Total Sectors
        26        2       Sectors/Track
                               9 for DD
                               18 for HD
                               10 for ED
        28        2       Sectors/Cylinder
                               typically twice sectors/track
        30        2       Number of tracks
        32        2       Sectors/Block
                               3 for DD and HD
                               1 for ED
        34        2       Block number of DIR EOF
        36        2       Byte number of DIR EOF
        38        2       sector offset/track (Skew Factor)
                               5 for DD
                               2 for HD and ED
        40       56       There then follow a table that has the
                          logical to physical translation
                          information.  There is one entry for each
                          possible logical sector, giving the
                          physical sector to which it translates.
                          If this would be on side two, the $80 is
                          added to the value.  Any remaining
                          entries in this table then contain $FF.

      96        variable  There is then a 3 byte entry for every
                          possible cluster on the disk.  The first
                          byte is the file number, and the last two
                          bytes the cluster number within the file.
Web: ZX Projects | Twitter: @zxprojects

Zerover
Jack The Nipper
Mensajes: 112
Registrado: Mar Abr 08, 2008 9:00 am

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por Zerover » Dom Jul 25, 2010 8:46 pm

badaman escribió:
Zerover escribió:Tengo una imagen de la ROM 5.3E, dime a dónde te la mando.


Aquí tenéis la imagen de Zerover.


Gracias, así es más fácil.

Zerover
Jack The Nipper
Mensajes: 112
Registrado: Mar Abr 08, 2008 9:00 am

Re: ROM de la interfaz de disco de MicroPeripherals

Mensaje por Zerover » Dom Ago 08, 2010 10:30 am

mcleod_ideafix escribió:[...] Q-emuLator [...] En resumen: que tengo que cambiar de emulador :?


Ahora puedes ser beta-tester de la nueva versión 3.0 para Windows escribiendo directamente a Daniele Terdina.

Daniele Terdina en sinclair-italy en Yahoo Groups escribió:Cerco altri beta testers per la prossima versione di Q-emuLator per Windows.
Se qualcuno e' interessato a fare da cav... ehm, a provare in anteprima la nuova
versione, contattatemi direttamente.
Ciao
Daniele


¡Quién sabe si te sorprende gratamente!

Responder

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 9 invitados