Sto cercando di creare un disco di avvio FreeDOS con OSX compatibile con la libreria V86 . Ho bisogno di farlo in un terminale (in uno script bash). Sto facendo tutto questo su OSX High Sierra.
Il disco di avvio che sto tentando di creare è un .img di un dischetto floppy. Sono consapevole che ci sono altri modi per fornire dischi di avvio a V86 come un'immagine del disco rigido o un cdrom .iso, ma sto provando in questo modo e vorrei almeno capire cosa sto facendo male.
Sospetto che il problema riscontrato sia nel tentativo di creare correttamente il Master Boot Record (MBR) dell'immagine del dischetto .
Per contesto, ecco la mia comprensione del processo MBR / avvio funziona:
Nei vecchi tempi su DOS o su macchine Win9x, mi sembra di ricordare di aver bisogno di eseguire un comando di formattazione con alcuni switch su di esso che renderebbero l'MBR sul disco anziché solo una tabella FAT nella parte anteriore del disco - anche se non sono sicuro di capire correttamente l'MBR.
La mia comprensione basilare e semplificata dell'MBR come quella dell'MBR sono i primi 512 byte del dischetto, che specifica quanto è grande il disco, nonché le istruzioni che dicono al BIOS di passare alla prima istruzione di un boot loader che comincerà il sistema operativo. Ad esempio, su un dischetto DOS c'è / c'era un campo COMMAND.COM su di esso. Presumibilmente in questo caso, l'MBR è stato scritto per comunicare al BIOS di avviare l'esecuzione sulla prima istruzione in COMMAND.COM.
Capire dove si trova la prima istruzione potrebbe essere complicato perché un certo numero di cose deve accadere (penso ..). I primi 512 byte del disco saranno riservati per l'MBR, dopo di che verrà scritto un FAT che prende altri X byte del disco, quindi dopo il FAT, c'è spazio vuoto per mettere i file in basso. Quando un file come COMMAND.COM viene scritto sul disco, la FAT viene aggiornata con le informazioni su dove sono memorizzati i byte sul disco. Affinché l'MBR sappia dove saltare per trovare la prima istruzione di COMMAND.COM, è necessario sapere dove è memorizzato COMMAND.COM, che potrebbe essere ovunque sul disco nello spazio vuoto dopo il FAT, giusto?
Ecco il mio attuale tentativo di creare il 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
Questo script mi avvicina all'avvio, l'avvio del V86 mostra "FREEDOS" piuttosto che lamentarsi del fatto che il disco non è avviabile, ma si blocca solo dopo aver detto "FREEDOS", invece di continuare il processo di avvio.
Ho anche provato vari altri modi / tentativi di creare l'MBR, in tutti questi casi ho creato il file img vuoto con il comando dd, quindi li ho eseguiti su di esso per creare l'MBR, quindi ho copiato i file come mostrato sopra .
# 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
Ho anche provato vari incantesimi in cui ho mescolato i comandi sopra, come l'esecuzione della partizione diskutil, quindi il comando fdisk -i per vedere se c'è qualcosa che fdisk farà per correggere l'MBR per la partizione esistente specificata.
Sono consapevole che ci sono molti modi per creare un dischetto avviabile, ma voglio farlo in uno script. Questi metodi sono elencati qui per completezza nel caso in cui altri siano alla ricerca di possibili modi per farlo:
1: Usa l'installer di FreeDOS in un ambiente virtuale come QEMU o VirtualBox, quindi salva un'immagine del dischetto creato.
2: Usa una macchina antica per creare un dischetto avviabile da un'installazione DOS o Windows effettiva.
Ho pensato che forse V86 ha una possibilità molto piccola di avviare un dischetto se qualcosa non va, il che non avrebbe senso come emulazione x86 appena emulata, ma ho provato a fare il boot anche da molti dei tentativi di creazione con qemu. Per chiunque voglia provare a farlo, puoi facilmente installare qemu con homebrew, quindi avviare una semplice VM con questo:
qemu-system-x86_64 -fda myfloppy.img
E un collegamento a un problema V86 in cui lo sviluppatore menziona come realizzare immagini QEMU tramite processi di installazione completi del sistema operativo che funzioneranno con V86:
Se non hai familiarità con V86, è un emulatore x86 scritto su asm.js che esegue un SO virtualizzato in un browser.
L'autore ha vari sistemi operativi demo Linux, Windows e DOS in esecuzione su v86 sul suo host personale:
Ci è voluto un po 'per capire come eseguire solo la sua immagine demo FreeDOS localmente senza la grande demo che richiede il download di più immagini del sistema operativo, ecco la mia fonte per questo:
<!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>
Il file .img di FreeDOS che funziona con V86 è stato recuperato da qui:
