Spin up a vm.
Install.
Image.
Write.

Freedos might have an image on their site.
But if you want a different dos, you're asking naughty things

PCem/86Box support IMG format, which can be written back to physical media by Win32DiskImager.
Or that Gnome Disk Utility, maybe.

virtualbox can be configured to use "vmdk" images (which have a flat DD capable image variant).

Given the recent nonsense with vmware, I would steer people away from it, but virtualbox is owned by oracle (arguably just as bad, but at least virtualbox is still free)

It's more involved to tell virtualbox to use a flat-image vmdk, (since it does NOT want to create that kind of image with the wizard, in my experience-- so you have to do it manually, or use vmware's tools to make it. Manual is easy enough though. Its basically like an old fashioned .cue sheet for cdrom .bin raw mode 2 images) but totally doable.

You are asking for trouble. I have found that there is only one reliable way to get DOS onto an old computer with modern flash storage, and that is to partition and format the drive using the actual DOS FDISK and FORMAT tools, from a floppy disk, or perhaps a Windows 98 installation CD (you can use that if you have to to get a basic DOS install)

They can always do both.

Set up the SDcard (such as with an SD->IDE) with DOS, (dont forget to fdisk /mbr that thing! Factory SDCards dont have proper mbr code!), then pull it out, pop it into a linux machine, and then DD it.

dd if=/dev/mmcblk0 of=./SDCard-Flat.vmdk bs=1m status=progress

get the size in bytes, then divide by 512 to get the number of sectors, then build a descriptor file.

Make backup copies of the prepared raw image, and set up whatever with a virtual machine, then write them to identical cards.

Try this: REMOVED

Burn to SD or CF with Balena Etcher. Worked flawlessly for me, after many failures trying other ways! Good luck!

keenmaster486 wrote on 2024-04-07, 05:00:

You are asking for trouble.

I was going to post the same thing 😁 I feel like the "YOU WILL REGRET THIS!" guy from SimCity 2000.

The scheme wierd_w proposes where you do the partitioning and format on the target system has worked for me (or at least I'm pretty sure it has).

Alternatively, you can figure out what geometry the target machine is going to treat the media as, then make sure that the emulator/hypervisor you use to create the disk image from scratch emulates exactly that geometry, but that can be harder than just doing the initial work on the target machine.

No trouble here, be sure to know what you're doing.

Does that 486 BIOS support LBA? If it does, you can boot into premade cards easily.

Also you won't find abundance of vmdk's or raw images for DOS. DOS system is a MBR, partition, boot sector and a bunch of files containing minimally command.com, so it's minimal and most of it depends on the geometry. The maximum partition size has changed between versions 2, 3, 3.31, and 5 if I recall correctly, while usage of DOS may be running base memory apps where you need a very small disk size, or running a 5 CD SVGA game via DPMI and fakecd, where you want 'huge' partitions.

1. Use a CHS online calculator to find CHS values that can fit the desired card; go under capacity a bit.
2. Get 86Box, run a machine with raw hdd image set to CHS values above.
3. Using DOS floppy images from REMOVED, perform DOS installation. Close the VM.
4. Using w32DiskImager or dd dump the image to the CF.

The above works for me out of the box on LBA-capable machines I have via a standard passive CF to IDE adapter to onboard IDE. The Trigem Pentium I have is roughly in era of some late 486 boards. The above works also on XT via XUB with a custom configured ROM on a CHS only BIOS.

If you want I can do some DOS CF image for you, just tell me the DOS version and CF size you have.

The 'problem' is that the logical ordering of LBA sectors does not always match the sectors returned by CHS addressing.

As such, you need to have the target system set up the MBR, and partition map, to be 100% sure.

Writing down what the target machine 'detects' as the drive geometry is also helpful.

While optional, there *ARE* descriptor entries you can put in the vmdk descriptor file to DEFINE the CHS geometry, for this very reason.

Like a spazz, I just failed to cite it in my examples.

I could understand asking this if you didn't have a floppy drive at all, but since you have a Gotek...

legodude wrote on 2024-04-07, 00:06:

skip hours of fool with my GOTEK

If you're seriously estimating hours for a three-floppy install, then it sounds to me like something might be off with your setup. If you expect to use it for anything else somewhere down the line then I recommend sucking it up and solving that problem first, and then install DOS "the right way". Otherwise you'll just end up having to do it later anyways.

REMOVED, it works like a charm.

It was removed when I linked it again here.. 😒

And it will be removed again if you post it another time. The mods here do not believe in the term "abandonware" and are very anal about piracy, and other thing they may perceive as such.

elszgensa wrote on 2024-04-08, 15:27:

And it will be removed again if you post it another time. The mods here do not believe in the term "abandonware" and are very anal about piracy, and other thing they may perceive as such.

ahhh ok fair. I thought it may have been a new user permission thing, but that makes sense. Thanks for the heads up!

wierd_w wrote on 2024-04-08, 13:11:

The 'problem' is that the logical ordering of LBA sectors does not always match the sectors returned by CHS addressing.

As such, you need to have the target system set up the MBR, and partition map, to be 100% sure.

Writing down what the target machine 'detects' as the drive geometry is also helpful.

And where exactly should CHS to LBA translation occur?
When you use raw disk images you use raw disk images, there is no extra metadata. The software can recognize the image geometry because it's written in the MBR both for CHS and for LBA.
On the other hand, CF card and USB connection are inherently LBA, regardless if the card is small enough that it can be addressed via CHS, like 32MB cards.

But as you say, the safest pick is to let BIOS on real machine autodetect the LBA settings, and then make a new LBA based raw image in the VM.

elszgensa wrote on 2024-04-08, 13:37:

If you're seriously estimating hours for a three-floppy install, then it sounds to me like something might be off with your setup.

Yes, I'm wondering if when OP says they want DOS, they mean DOS plus all the other things you expect to come with DOS like, I don't know, Phil's boot menu, DOOM, and Lotus 1-2-3? 😁

zb10948 wrote on 2024-04-08, 18:45:

the safest pick is to let BIOS on real machine autodetect the LBA settings, and then make a new LBA based raw image in the VM.

Back in the day, I always did the first step on the target machine (run FDISK, set up a primary partition, then activate it).

Formatting it right away also was helpful, sometimes.

I've used to use FORMAT C: and SYS C: (equivalent to FORMAT C: /S), too, until a wierd Windows 9x distribution refused to install on such a disk (it didn't like to see MS-DOS, for bureaucracy/license reasons).

That's when I've switched to do FORMAT C: /B on anything Windows 9x.
It reserved space for system files, but didn't copy them.

Instead, I've copied WINDOWS directory over and re-booted via boot floppy, then I've started Setup inside C:\WINDOWS.
With the usual switches.

(The text above was about Windows 98 SE, mainly. A plain DOS installation didn't require this procedure, of course.)

Edit: Another method in the medieval times (286/early 386 PCs) was to pick up one of the pre-defined HDD TYPEs.

If I'm not mistaken, they're still included within newer 486 BIOSes.
Last time I've checked, the Setup Utility of WinBIOS had a long list of HDDs, including an userdefinable one.

The downside is, though, that the largest entry has 120MB or so.
That's a bit too little nowadays. In 2004, when many CF cards being sold were still in the 8 to 256 MB range, it was still an option, perhaps.

zb10948 wrote on 2024-04-08, 18:45:

And where exactly should CHS to LBA translation occur? When you use raw disk images you use raw disk images, there is no extra […]
Show full quote

wierd_w wrote on 2024-04-08, 13:11:

The 'problem' is that the logical ordering of LBA sectors does not always match the sectors returned by CHS addressing.

As such, you need to have the target system set up the MBR, and partition map, to be 100% sure.

Writing down what the target machine 'detects' as the drive geometry is also helpful.

And where exactly should CHS to LBA translation occur?
When you use raw disk images you use raw disk images, there is no extra metadata. The software can recognize the image geometry because it's written in the MBR both for CHS and for LBA.
On the other hand, CF card and USB connection are inherently LBA, regardless if the card is small enough that it can be addressed via CHS, like 32MB cards.

But as you say, the safest pick is to let BIOS on real machine autodetect the LBA settings, and then make a new LBA based raw image in the VM.

As I wrote in my reply above, the descriptor file CAN specify CHS geometry to the VM. (Just almost nobody uses that, though.)

You are correct that a chs partition will contain data about head and sector numbering, which leaves the bios/image handler enough data to compute full max cylinder number.

Telling the VM what that data really, truly is, works better though.

Most modern vm suites dont let you specify that (visibly).

Vmdk descriptors very much can present this to the vm, though.

For the curious, one can pass this data using these directives/descriptors in the descriptor file's bottom section.

ddb.adapterType = "ide" ddb.geometry.sectors = "63" ddb.geometry.heads = "16" ddb.geometry.cylinders = "10402" […]
Show full quote

ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "10402"

Just replace with your geometry that properly adds up to your total sectors defined in the extent section prior.

If your vm PROPERLY supports vmdk files, it will use the geometry you specified for the lba translation.

Taken together with letting the target system set up the mbr and partition table, and recording what the target system detects the geometry as, the above *should* give reasonable assurances that your vm will play nice with real world expectation, at least as far as disk structures are concerned.

@legodude

You could try the SvarDOS "bleeding edge" build 20240415.
Maybe the USB image works for you. (SvarDOS uses an older FreeDOS kernel, but comes with it's own COMMAND.COM named SvarCOM.)

wierd_w wrote on 2024-04-09, 07:01:

As I wrote in my reply above, the descriptor file CAN specify CHS geometry to the VM. (Just almost nobody uses that, though.) […]
Show full quote

zb10948 wrote on 2024-04-08, 18:45:

And where exactly should CHS to LBA translation occur? When you use raw disk images you use raw disk images, there is no extra […]
Show full quote

wierd_w wrote on 2024-04-08, 13:11:

The 'problem' is that the logical ordering of LBA sectors does not always match the sectors returned by CHS addressing.

As such, you need to have the target system set up the MBR, and partition map, to be 100% sure.

Writing down what the target machine 'detects' as the drive geometry is also helpful.

And where exactly should CHS to LBA translation occur?
When you use raw disk images you use raw disk images, there is no extra metadata. The software can recognize the image geometry because it's written in the MBR both for CHS and for LBA.
On the other hand, CF card and USB connection are inherently LBA, regardless if the card is small enough that it can be addressed via CHS, like 32MB cards.

But as you say, the safest pick is to let BIOS on real machine autodetect the LBA settings, and then make a new LBA based raw image in the VM.

As I wrote in my reply above, the descriptor file CAN specify CHS geometry to the VM. (Just almost nobody uses that, though.)

You are correct that a chs partition will contain data about head and sector numbering, which leaves the bios/image handler enough data to compute full max cylinder number.

Telling the VM what that data really, truly is, works better though.

Most modern vm suites dont let you specify that (visibly).

Vmdk descriptors very much can present this to the vm, though.

For the curious, one can pass this data using these directives/descriptors in the descriptor file's bottom section.

ddb.adapterType = "ide" ddb.geometry.sectors = "63" ddb.geometry.heads = "16" ddb.geometry.cylinders = "10402" […]
Show full quote

ddb.adapterType = "ide"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "10402"

Just replace with your geometry that properly adds up to your total sectors defined in the extent section prior.

If your vm PROPERLY supports vmdk files, it will use the geometry you specified for the lba translation.

Taken together with letting the target system set up the mbr and partition table, and recording what the target system detects the geometry as, the above *should* give reasonable assurances that your vm will play nice with real world expectation, at least as far as disk structures are concerned.

This is the reason why I prefer dedicated paravirtualizers such as 86Box that don't hide these sorts of options and emulate dedicated hardware of the era. Instead of using a desktop hypervisor - the version of VMWare Workstation I have is couple of years old but it still doesn't allow GUI configuration of direct disk passthrough, you need to edit files yourself. So it's not only about retro stuff CHS and so on, but anything out of the usual workflow you need to dig into config files.

So yeah your recommendation of vmdk's is worthwhile because you always have the sizing metadata present somewhere outside of content image. And 86Box can do that from GUI too.