Estoy intentando hacer un disco de arranque de FreeDOS con OSX que sea compatible con el Biblioteca V86 . Necesito hacer esto en terminal (en un bash script). Estoy haciendo todo esto en OSX High Sierra.
El disco de arranque que estoy intentando crear es un .img de un disquete. Soy consciente de que hay otras formas de proporcionar discos de arranque a V86 como una imagen de disco duro o un cdrom .iso, pero estoy probando de esta forma y me gustaría al menos entender qué estoy haciendo mal.
Sospecho que el problema que estoy teniendo es al intentar crear correctamente la imagen del disquete Registro de arranque maestro (MBR).
Para contextualizar, esto es lo que entiendo del funcionamiento del MBR/proceso de arranque:
En los viejos tiempos en DOS o en máquinas Win9x, me parece recordar que era necesario ejecutar un comando de formato con algunos interruptores en él que haría que el MBR en el disco en lugar de sólo una tabla FAT en la parte delantera del disco - aunque no estoy seguro de si estoy entendiendo MBR correctamente.
Mi comprensión básica y simplificada del MBR es que el MBR son los primeros 512 bytes del disquete, que especifican el tamaño del disco, así como las instrucciones que indican a la BIOS que salte a la primera instrucción de un cargador de arranque que pondrá en marcha el sistema operativo. Por ejemplo, en un disquete DOS hay/había un campo COMMAND.COM en él. Presumiblemente en ese caso, el MBR fue escrito para decirle a la BIOS que iniciara la ejecución en la primera instrucción de COMMAND.COM.
Averiguar dónde está la primera instrucción parece que puede ser complicado porque tienen que pasar varias cosas (creo ). Los primeros 512 bytes del disco se reservan para el MBR, después se escribe una FAT que ocupa otros X bytes del disco, después de la FAT, hay un espacio vacío para poner archivos. Cuando un archivo como COMMAND.COM se escribe en el disco, la FAT se actualiza con información sobre el lugar del disco donde se almacenan los bytes. Para que el MBR sepa dónde saltar para encontrar la primera instrucción de COMMAND.COM, necesitaría saber dónde se almacena COMMAND.COM, que podría estar en cualquier parte del disco en el espacio vacío después de la FAT, ¿verdad?
Aquí está mi intento actual de crear el disco:
# create a 720k empty img file with all zeros in it
dd if=/dev/zero of=myfloppy.img bs=1024 count=1440
# attach our .img file without mounting it, saving the attached name such as "/dev/disk2" in the var ${DEVICE}
DEVICE=`hdiutil attach -nomount myfloppy.img`
# attempt to use diskutil to format the device as a bootable FAT12 diskette
# question: are dos boot diskettes supposed to be FAT12, FAT16, or FAT32?
diskutil eraseVolume "MS-DOS FAT12" MYFLOPPY bootable ${DEVICE}
# detach our unmounted .img file
hdiutil detach $DEVICE -force
# mount our source freedos image fetched from the V86 demo page, this mounts as /Volume/FREEDOS
# note that this sample image is also 720K
hdiutil mount freedos722.img
# mount our target .img file we just created, it'll mount as /VOLUMES/MYFLOPPY
hdiutil mount myfloppy.img
# copy minimal set of files necessary to boot the disk (probably dont need autoexec.bat ..)
# question: does the copy order of these files matter?
cp /Volumes/FREEDOS/COMMAND.COM /Volumes/MYFLOPPY/
cp /Volumes/FREEDOS/KERNEL.SYS /Volumes/MYFLOPPY/
cp /Volumes/FREEDOS/CONFIG.SYS /Volumes/MYFLOPPY/
cp /Volumes/FREEDOS/AUTOEXEC.BAT /Volumes/MYFLOPPY/
# unmount our disks
hdiutil unmount /Volumes/MYFLOPPY/
hdiutil unmount /Volumes/FREEDOS/
#TODO: might need to detach our image files even though we did mount/unmount above
Ese script de arriba me acerca al arranque, el arranque del V86 muestra "FREEDOS" en lugar de quejarse de que el disco no es arrancable, pero simplemente se cuelga después de decir "FREEDOS", en lugar de continuar el proceso de arranque.
También he probado otras formas/intentos de crear el MBR, en todos estos casos creé el archivo img en blanco con el comando dd, luego lo ejecuté para crear el MBR, luego copié los archivos como se muestra arriba.
# Attempt #1: After the files are copied to the target disk, try to copy the 512 byte MBR from the source image to mine, if this worked I would be surprised, it didn't.
# this shouldn't work afaik because the MBR on the source image will have instructions to jump to the first instruction in COMMAND.COM as it's layed down on the source disk, which likely isn't where it is on our target disk.
dd if=freedos722.img of=myfloppy.img bs=512 count=1 conv=notrunc
# Attempt #2: try using the diskutil partition instead of erase disk command
diskutil partitiondisk ${DEVICE} 1 MBR "MS-DOS FAT12" "MYFLOPPY" 100%
# Attempt #3: try same as above, but with FAT16 (shouldn't work, didn't, because source img was FAT12)
diskutil partitiondisk ${DEVICE} 1 MBR "MS-DOS FAT16" "MYFLOPPY" 0B
# Attempt #4: use the newfs_msdos command without any diskutil commands
newfs_msdos -F 12 -v MYFLOPPY $DEVICE
# Attempt #5: use fdisk rather than any diskutil or newfs_msdos commands
# I *think* this is making an MBR, but not sure, maybe just making a partition
#note that I have no idea what to specify here for cylinders (c) and heads (h) and just copy/pasted this from somewhere
fdisk -i -c 1024 -h 255 -s 1440 -b 512 -a dos ${DEVICE}
# Attempt #6: use fdisk to create MBR / FAT, then use fdisk to mark that partition 'active'
fdisk -i -c 1024 -h 255 -s 1440 -b 512 -a dos ${DEVICE}
fdisk -e ${DEVICE}
#fdisk -e puts us in an interactive edit mode, so we do the following
type 'a', then enter # gets us into 'set partition as active' mode
type '1', then enter # sets partition as active
type 'w', then enter # writes the MBR with the partition now marked active
También he probado varios conjuros en los que mezclo los comandos anteriores, como ejecutar diskutil partition y luego ejecutar el comando fdisk -i para ver si hay algo que fdisk haga para arreglar el MBR de la partición existente dada.
Soy consciente de que hay formas largas de crear un disquete de arranque, pero quiero hacerlo en un script. Estos métodos se enumeran aquí en aras de la integridad en caso de que otros están buscando posibles maneras de hacer esto:
1: Utiliza el instalador de FreeDOS en un entorno virtual como QEMU o VirtualBox, y luego guarda una imagen del disquete creado.
2: Utilice una máquina antigua para crear un disquete de arranque a partir de una instalación real de DOS o Windows.
Pensé que tal vez V86 tiene una posibilidad muy estrecha de arrancar un disquete si algo está mal, lo que no tendría sentido ya que su sólo emulando x86, pero he intentado arrancar desde varios de los intentos de creación con qemu también. Para anyoen que está tratando de hacer eso, usted puede instalar fácilmente qemu con homebrew, a continuación, arrancar una simple VM con esto:
qemu-system-x86_64 -fda myfloppy.img
Y un enlace a una edición de V86 donde el desarrollador menciona cómo hacer imágenes de QEMU a través de procesos completos de instalación del SO que funcionarán con V86:
https://github.com/copy/v86/issues/128
Si no estás familiarizado con V86, es un emulador x86 escrito sobre asm.js que ejecuta un sistema operativo virtualizado en un navegador.
El autor tiene varios sistemas operativos de demostración de Linux, Windows y DOS que se ejecutan en v86 en su host personal:
Me costó un poco averiguar cómo ejecutar sólo su imagen de demostración de FreeDOS localmente sin la gran demostración que requiere la descarga de múltiples imágenes del sistema operativo, aquí está mi fuente para eso:
<!doctype html>
<script src="libv86.js"></script>
<script>
"use strict";
window.onload = function() {
var emulator = window.emulator = new V86Starter({
memory_size: 32 * 1024 * 1024,
vga_memory_size: 2 * 1024 * 1024,
screen_container: document.getElementById("screen_container"),
bios: { url: "seabios.bin", },
vga_bios: { url: "vgabios.bin", },
fda: { "url": "freedos722-t.img", },
autostart: true,
});
}
</script>
<div id="screen_container">
<div style="white-space: pre; font: 14px monospace; line-height: 14px"></div>
<canvas style="display: none"></canvas>
</div>
El archivo .img de FreeDOS que funciona con V86 fue obtenido de aquí:
0 votos
Los disquetes no tienen un MBR. Históricamente, el formato de disquete de IBM existía antes de que se pensara en el MBR.
0 votos
Es interesante. ¿Qué es lo diferente de un disquete de arranque comparado con un disquete normal, entonces? ¿Las primeras instrucciones para que la BIOS salte siempre se escriben en un determinado byte del disco, por lo que mis trabajos de copia anteriores no se alinearían?
0 votos
Considere la posibilidad de que el ordenador de arranque de la BIOS intente arrancar desde una unidad que contiene un MBR. El firmware carga el MBR en la RAM y ejecuta el software almacenado en el MBR. (El MBR se almacena en el primer sector de la unidad.) Este software mira la tabla de particiones del MBR y determina qué partición está activa. A continuación, este software carga el Volume Boot Record (VBR) de la partición activa en la memoria y ejecuta el software almacenado en el VBR. (El VBR se almacena en el primer sector de la partición activa.) A partir de aquí, se completan más pasos para terminar de arrancar el ordenador.
0 votos
Ahora, considere la posibilidad de que el ordenador que arranca con la BIOS intente arrancar desde una unidad de disquete. No hay MBR. El firmware carga el Volume Boot Record (VBR) en la memoria y ejecuta el software almacenado en el VBR. (El VBR se almacena en el primer sector de la unidad.) A partir de aquí, se completan más pasos para terminar de arrancar el ordenador.
0 votos
En cuanto a las preguntas planteadas en su comentario, aquí está mi respuesta. Si se puede arrancar, entonces habrá al menos código de arranque almacenado en el VBR. Con otros sistemas operativos, puede haber más código de arranque en sectores posteriores, pero FreeDos parece que sólo necesita el VBR. El resto del código necesario para terminar de arrancar se almacena en archivos.
0 votos
Gracias por todos los detalles. No había oído hablar de un VBR antes y eso ayuda a aclarar mi malentendido en gran medida.
0 votos
En particular, la búsqueda en Google de VBR me llevó a este increíble recurso para MBR y VBR con detalles a nivel de bytes explicados para MSDOS 5.x de forma detallada y fácil de entender aquí .