Note, any 800k image written to a floppy this way wastes space on the floppy disk, and the disk requires a 1.44M "SuperDrive" (a name Apple has reused time and again, but in this context refers to machines able to support the 1.44M floppy and equipped with such a drive.) Similar tricks can be used for Apple // ProDOS and GS/OS disk images if the machine is equipped with a SuperDrive and controller or other PC-compatible 1.44MB drive. This leaves you with a raw disk image suitable for use with emulators or writing to a floppy as above. Now to convert that to a raw image, you can use dd to trim off the Disk Copy header: dd bs=84 skip=1 if=disk_image.dmg of=disk_image.img dmg extension and running truncate -s 819284 your_image.dmg to produce a Disk Copy image. Note, you'd be wise to use lsar on the file first as Macintosh files contain characters like spaces rather commonly and unar does not provide an option to rename the output file during extraction.Īt this point I recommend renaming or copying the. If the image is wrapped in BinHex, we can use The Unarchiver's unar/ lsar to unpack the file. We'll address that first since it's far more common. sea self-extracting disk image, possibly with a BinHex (. It will be either a Disk Copy image (819284 bytes) or a. However, if the image you are using comes from Apple, it will not be raw. Just fdformat the floppy device for 1.44MiB as you would for any other DOS/Windows/Linux machine and write the image using a command like, dd bs=512 if=floppy_image.img of=/dev/floppy If the image you're using is a raw image (819200 bytes exactly, often used by emulators, that's easy. Here's what I've been able to determine: A short filesystem on a floppy should work fine, as long as the blocks are in the right order.
0 kommentar(er)
