MiSTer FPGA Forum

Would anyone here happen to know of any sort of in compatibility between GNU mtools and old versions of MS-DOS? I'm writing a tool that generates bootable hard disk images and everything is just fine from 6.22 down to 4.00 but 3.31 and 3.30 won't boot in PCem when I generate the image with mtools.

DOS boots just fine on disks that it partitions and formats itself, but not my mtools-generated ones. They don't have errors on them though. Once booted from a floppy the images function just fine. So my suspicion is with mtools, specifically mpartition or mformat..

I try to boot from one of my images and the PCEm machine (a 486 for performance purposes) just hangs, hard, for about 10 seconds before seemingly trying to jump into the BIOS setup and failing to do so. On an emulated 8088 the hang seems permanent. No error messages from the mbr or vbr.

Anyway, just throwing this out here hoping for the wisdom of the crowd to nudge me in the right direction.

It's been a while since I played with DOS disks on modern systems, but what I remember: boot needs "full" MBR with the actual boot code. Most of the contemporary tools write partition table only. I think mtools have an option to use MBR "template". That may solve booting. Disclaimer: it didn't in my case.

Non-bootable disks should be easier, just watch the FAT type. Again, most modern tools fall back to VFAT, something that older DOS won't understand.

I got the booting down for DOS 4.00 through 6.22 with mbr and vbr's from the original systems. The exact same trick chokes on 3.31 and lower though. Nothing changed other than the DOS versions. That's what got me stumped. Will be breaking out the hex editor tomorrow..

Yep, that was the point when I gave up (after looking at the hex dumps) and started using pre-formatted (in 86Box) floppy images. After all, PC DOS 2.10 bootable floppy image compressed is about 28K. One thing I remember, there is no need to extract MBR from an image, mformat will happily use the first 512 bytes from the -B file.

My theory was that earlier DOS'es boot sectors did not read FAT properly, but were rather loading IO.SYS from a hardcoded specific sectors, perhaps outside of the normally allocated area. And modern tools fail to write it to those exact sectors.

As my hex editor tells me, MS-DOS 3.30 and Mtools do things differently in the partition boot record and the way FAT is laid out. I'm going to try a few things in this order:

1. See what a partition boot record from DOS 4.x does when paired with DOS 3.3x system files. As long as the 3.x versions of the system files do get loaded, then for all intents and purpose we are running the real thing. Nobody ever looks at the boot records again once the system is running. Not very historically accurate though.. so meh..

2. If 1 doesn't lead to anything useful, whip out either C or Rust yet again and cook up something that lays down a filesystem base structure that's 100% identical to what MS does in their ancient OS'es. If I'm going to do that, I may just as well ditch mformat and mpartition altogether.

I really want to avoid 2 because I want my toolbox to be portable and I don't like having compiled custom stuff in there. Maybe something like this is doable with binary patching using an existing tool, but I'm not really up to speed on that.. ideally something as ubiquitous as SED, but for binaries.

Scratch 1.. doesn't work.. So for now my toolbox won't go further down in history than MS-DOS 4.00 and I'm skipping 2 for now. Too much head scratching involved. I'm going to focus on actually releasing something that works so that it can be improved upon later.

I don't know if this is a factor, but DOS 3.x and earlier have a maximum partition size of 32 MB. To use larger partitions requires a third-party tool, like Ontrack Disk Manager.

If you want to go back to DOS 2.x, there are other format changes involved as well.

mdkoehn wrote: ↑Tue Dec 19, 2023 5:00 pm

I don't know if this is a factor, but DOS 3.x and earlier have a maximum partition size of 32 MB. To use larger partitions requires a third-party tool, like Ontrack Disk Manager.

Compaq DOS 3.31 allows for up to 2GB