Como podréis ver en algunos de mis últimos vídeos, finalmente logré emular el microdrive en ZEsarUX.
https://youtu.be/j7MDpgR_wrc?si=tlg7SyTQenMpsg_T
https://youtu.be/IdKOnsrCqWo?si=eYrNXS1TqidUMYdf
https://youtu.be/2wsrP88nVZk?si=FJBYj5_NVh8fnyNN
Incluso agregué algunas herramientas como:
- Verificar el disco "chkdsk"
- Explorar archivos
- Mapa de Microdrive (para ver los sectores ubicados en cada archivo)
- Visual Microdrive (para ver cómo es un microdrive por dentro)
- Incluso emular sectores erróneos
Lo encuentro muy interesante y un dispositivo sorprendente que creó Sinclair (a pesar de su poca fiabilidad).
Sin embargo, todo mi código de emulación depende de tener un formato de microdrive estándar creado por la ROM de la Interface 1 (y el formato MDR descrito aquí: https://worldofspectrum.org/faq/reference/formats.htm )
Por lo tanto, se espera que un sector tenga 15 bytes de datos de encabezado, el descriptor de registro, 512 bytes de datos... y las secciones de gap y preamble (preámbulo).
Como las secciones de gap y preámbulo no están escritas en el archivo MDR (se ignoran), eso significa que este formato MDR solo puede contener microdrives creados por la ROM de la Interface 1.
Realmente dudo que nadie haya creado (y no creará) un microdrive con un formato diferente (hablando del Spectrum, no del QL que tiene otro formato), pero me pregunto si puedo tener un formato de archivo de microdrive diferente (diferente al MDR), para contener cualquier formato diferente que se pueda crear: uno con diferentes secciones de encabezado, diferentes secciones de preámbulo, etc.
Y aquí viene mi pregunta:
Según veo en mucha información y en el desensamblaje de la rom de Interface 1, una sección de preámbulo son 10 bytes con valor 0 y 2 bytes con valor 255:
; -------------------
; THE 'PREAMBLE DATA'
; -------------------
; The PREAMBLE consists of twelve distinctive bytes that are saved to a
; microdrive cartridge before the data. They are not read back but allow
; the ULA of the microdrive to recognize the start of a saved data block.
;; PREAMBLE
L14CA: DEFB $00, $00, $00
DEFB $00, $00, $00
DEFB $00, $00, $00
DEFB $00, $FF, $FF
Entonces, si estos bytes se usan para reconocer una sección de preámbulo (y creo que la ula de la interface 1 decodifica esta sección), si una persona almacena esta secuencia de bytes en un archivo de microdrive (10 bytes 0, 2 bytes 255), la ula del interface 1 reconocerá (erróneamente) esta secuencia de bytes como una sección de preámbulo y la lectura fallará. Creo que esto no es cierto y se utilizan otros parámetros para reconocer una sección de preámbulo. Por ejemplo: cuando la rom de la interface 1 desea escribir una sección de preámbulo, tal vez active algún bit de E/S de hardware para que almacene estos bytes de forma diferente a cuando se escriben bytes normales. O tal vez, la temporización de una sección de preámbulo es diferente a la de los bytes normales. O quizá la intensidad de una señal de preámbulo sea mayor que los bits de datos.
El desensamblaje de la rom no explica como funciona eso. También vi algo de información aquí:
https://sinclair.wiki.zxnet.co.uk/wiki/ ... age_Format
Y estos diagramas parece que muestren que los pulsos de sincronización (preámbulo) tienen la misma temporización que los bytes normales...
Por cierto, en mi código de emulación en ZEsarUX simplemente me salto estas secciones de preámbulo y espacio y conozco la posición donde el microdrive está leyendo o escribiendo mediante un contador:
- Al leer, si está ubicado en una posición de gap o preámbulo (como dije, mirando mi contador), simplemente activo los bits GAP/SYNC en el puerto EF.
- Al escribir, si está ubicado en un gap o posición de preámbulo, simplemente no grabo ese byte y me lo salto.
A ver si alguien sabe estas dudas... Gracias!