Dosbox Hard Disk Image Download
Jeuel Barrientos
Do you people have any idea how to work this, specifically clone a existing bootable win95/98 disk image into a larger or smaller new disk image? Normal drives ofc transfer fine with mtools using the trick of placing a 'custom config file' in a environment variable to mount the old image and the new image as mtools 'drives' and copying them over with permissions (this is needed because nuking the actual file is impolite and because there is no way to specify 2 hard disk images as source and destination in the mtools copy command otherwise, though there is a way for the destination hdd image).
It's already useful, to transfer files to/into a smaller or larger disk image without using dosbox or windows fallible copy tools or using the native linux fat support (which doesn't preserve DOS attributes and requires root and skipping the MBR if any, which is complicated as heck), but it feels incomplete without the capability, though i might just bail out in bootable hard disks if it can't be made to work.
I'd also probably add the capability to copy over a linux dir into a new hard disk image, for the 'install in wine, run in dosbox' usecase to avoid all of the cases where the user has to understand how to natively mount a dosbox image even if i show how.
I tried that approach with the images produced by parted/mformat above. It didn't work. Also to be clear i want a approach that works completely outside dosbox/DOS/Windows and user interaction. Fire and forget and never do that stuff again, preferably without touching sudo. I've 'done it' (the mtools project did it) to non-bootable stuff but not bootable. Even tried to use your way (native OS) format to do the formatting instead of mformat, but didn't really make a difference (maybe it hanged on boot instead of the ms-sys 'didn't find the OS' message, can't quite recall).
Besides, i tried the manual step as i said and it didn't work for unknown to me reasons. If you want to try it, switch the 'boot off' flag on the parted part of the script to 'boot on' and try to transfer a windows 95/98 image with the -c flag in the script, then do the sys c: d: thing by mounting both and booting the original in dosbox (or a bootdisk that works and the new). Since all files were copied by mcopy (including system files) and since mcopy preserves attributes, including the system bit, there is no need of that slow internal copy.
We should really take this to the dosbox-x thread. But with the latest dosbox-x release you can now run sys, fdisk and format directly from the integrated DOS. All you need to do is set the right dos version to match that of the sys/fdisk/format utilities. The only known issue at this point, is that you cannot format an image that is not already formatted (blank disk). As such you don't actually need the boot, press f5, sys steps, but can replace them with "set ver 7.1" and running "c:\windows\sys c: d:"
0 represents drive A: and 1 represents drive B:, but due to the use of drive numbers they cannot be directly accessed from the DOSBox-X integrated DOS. Note that when using drive numbers like 0 and 1 to mount a diskette image the -fs none flag is automatically assumed in DOSBox-X. For vanilla DOSBox, or other forks, the -fs none flag will be required.
By default, diskette images are mounted read-write.It is possible to make a diskette image read-only (write protected) either by using the -ro option, or by attaching the : prefix to the filename.e.g.
They can also be used when mounting multiple diskette images.If you use the -ro option, then all images specified in the command will become read-only.On the other hand, if you wish to make individual images read-only (instead of all of them), then you can attach the : prefix to these images, like this:
GNU mtools is an optional package you can install to interact with DOS disks or disk images.It provides various commands which can be used to interact with DOS diskette images without having to mount them.
DOSBox-X has a built-in IMGMAKE command with which you can create partitioned and FAT formatted harddisk images in RAW MFM sector image format from the DOSBox-X command prompt.IMGMAKE only creates a single primary DOS partition per harddisk image file.
The FAT version will be automatically selected, based on the aggregate amount of files in the folder, plus (by default) 250MiB of free space.If the total does not exceed 2GiB, it will be converted to a FAT16 harddisk image file, otherwise it will become a FAT32 image instead (which will require a guest OS with FAT32 support).
The above assumes oakcdrom.sys and mscdex.exe are in the C:\DOS directory in the harddisk image file.You can substitute oakcdrom.sys and mscdex.exe with their FreeDOS equivalents with the same parameters.
The advantage of the QCOW2 format, is the Copy-On-Write (COW) functionality which allows you to create a base image of for instance Windows 98, and then have different snapshots on top of that with different drivers or applications.This saves disk space compared to maintaining multiple full installations, and can prevent Windows bit-rot.
The above will try to read the real A: drive on your Windows PC, and convert it to a disk image named disk.ima. The -r option specifies how many retries are allowed while reading the original diskette.
You should also verify the two images have mounted correctly by seeing that drive 0 was mounted as WIN98C.img (also known as the A: drive) and drive 2 is mounted as your hard drive image (also known as the C: drive).
However, before you start using your old MS-DOS application with modern hardware, do be aware that old MS-DOS applications might not be able to handle current hardware any more. Modern CPU's are way too fast for most, the graphic cards support far more complex modes than they used to and best of all, hard disks have become huge, compared to what was common for MS-DOS.
In 1990 I had a pinball game for MS-DOS, which was real fast back then. In 2000 I played the same game a few times, although you couldn't really call it playing anymore. I would start the game and I'd immediately hear a beep telling me the game was over. But at least I did see the ball move over the screen. On my current system, I tried it again and this time I did not even see the ball any more. Still amazing that an application that old would still run after 20 years, but unfortunately it's one of the few that can handle modern hardware. Many other MS-DOS applications will refuse to run on my system, complaining that I have a negative amount of disk space or memory. (I have a 1 TB disk and 12 GB of RAM...) These applications were written in a time when 16-bits applications ruled the world and memory could be addressed by just 20 bits. Nowadays, they generate all kinds of overflows and underflows and some even make some invalid processor calls, that might make your (virtual) system crash over and over again.
When trying to copy the program to other systems (trying to check if it works in compatibility mode), we get a stern warning from the program telling us that if we use defrag or compactation tools the software may lose its "serial". I understand that the software is trying to do some checks in the contents of the hard disk (probably in which sectors the program is stored) in order to check if it is a legal copy.
If it's MS-DOS, have you looked at a light-weight solution like DOSBox? It exists mainly to play old DOS games on modern hardware. I can't tell from glancing at the documentation, but you may be able to mount the disk image file you create from dd in DOSBox. If you can't do it directly, there should be a way to convert the image file.
Ah, it looks like there are tools to convert dd output for VirtualBox, so if DOSBox doesn't work out, there is that route. I'm sure VMWare will have a similar tool (search term might be something like "covert raw image to" (whatever the VMWare virtual hard drive format is called).
A) If this is an older drive, it'll have a particular disk geometry (cylinder, sectors, heads) that I wonder if a disk image would work transcribed to a new hard disk. If the program is really that old and it's searching particular sectors (terrible DRM, by the way...) the drive won't necessarily work when you place the image back to the new disk.
If you still want to try it, create your backup first so you can restore the disk if it gets screwed up and use a Linux disk to dd the drive to a raw disk image, then use Virtualbox's utilities to transform the raw disk into a vhd image that it can read and attach it to a new VM. That will tell you if it'll work with Virtualbox; that's the first step I'd attempt. Make sure you have a second disk installed that can hold the entire disk you're imaging.
You can switch disks by hitting Ctrl + F4. Each time you switch disks, it will mount the next image you passed to the boot DOSBox command, until you cycle around to the first disk again. The setup will now complete itself, prompting only when it requires the next floppy disk to be mounted.
One thing to be very careful of is to avoid having multiple DOSBox instances mounting the same disk image. Writing to a disk image simultaneously from different DOSBox instances can cause the disk image to become corrupted. I would also recommend always specifying the disk geometry when mounting disk images. Failing to do this can result in DOSBox being unable to determine the disk geometry under certain circumstances, for example in the case that the number of heads is not 16.
However, after using Mini vMac on my 2019 MacBook Pro to transfer the Lemmings files over to the correct hard disk volume on the microSD card, I was able to open Lemmings on the Classic. I went ahead and transferred the files from the FloppyEmu to the internal hard drive.
I'm looking for a driver to emulate a real disk drive on MS-DOS running on an 8088 from an image hosted on other computer, served by serial port, because I have an USB to Serial converter and a null-modem cable.
35fe9a5643