Well, the problem might be that in the boot process both IO.SYS and IBMBIO.COM have to be starting at cluster 2 and to be unfragmented.
The routines in boot sector do not really care about file system, root directory and FAT.

I think the same. This was one of the big differences between MS-DOS 6.22 and 7.0.
Previously, system files had to be located at a specific, fixed location, essentially.
From DOS 7 onwards, things like command.com could be located in sub directories etc.
The DOS 7 boot code was more intelligent or flexible, so to say.

make new empty image.
create primary active partition in this new empty image
make copy of this image with primary active partition
do a sys c: of romdos on one copy
do a sys c: of MS-DOS (Win98/Me) on other copy
... ? compare data of both images not looking at FAT tables, directory or partition data sectors.

While old dos version definitely had this annoying thing where io.sys/ibmbio.com needed to be the first file on the disk, I'm fairly certain that was no longer the case for the later dos/windos versions. IIRC
So modifying one of those bootsectors to load the correct files might also bring relief.

Just checked my experiment logs... I should have mentioned this earlier.

It seems both DOS can boot okay, without the issue I'm having, when using a FAT16 partition, but that would severely limit my primary partition to 2GB.

I'm currently doing this on a FAT32 primary partition with at least 16GB (as I also plan to install other stuffs like Windows afterwards, though it needs to be done on real machine), and I'm having this problem.

Since the "lba" flag needs to be set for FAT32 primary partitions above 8GB (crossing the CHS boundary), I'm not sure if this was case. Some partition managers like PartitionMagic does this automatically when resizing a FAT32 beyond the 8GB boundary.

Maybe I can experiment this with a 6-8GB FAT32 (before CHS boundary) and see if everything works... but I'm not sure if the "lba" flag was really that necessary for some OSes to access larger FAT32 partitions (above 8GB) properly...

EDIT: Reproduced the same issue on FAT32 partitions without LBA flag (0x0b) as well, regardless of its size. While not having the LBA flag may not be an immediate issue it seems when trying to install Windows 9x, ScanDisk does care about the absence of the LBA flag and would go as far as forcing a surface scan.

EDIT 2: Still reproducible under many different configurations. A side note: It seems ROM-DOS's SYS command would somehow remove IO.SYS/MSDOS.SYS, but it doesn't seem to matter even after putting those files back. Guess I really need to look into the boot sector dumps to figure out what was going on behind the scenes.

MS-DOS 7.1 supports LBA, according to Wikipedia.

"MS-DOS 7.1 added FAT32 support (up to 2TB per volume),
while MS-DOS 7.0 and earlier versions of MS-DOS only supported FAT12 and FAT16.
Logical block addressing (LBA) is also supported in MS-DOS 7.1 for accessing large hard disks,
unlike earlier versions which only supported cylinder-head-sector (CHS)-based addressing.
Year 2000 support was added to DIR command via the new /4 option. "

Source: https://en.wikipedia.org/wiki/MS-DOS_7

Maybe there's a subtle difference between these two.
Msybe the Partition ID or something along these lines?

Partition ID is definitely different for fat12/16 & fat32

weedeewee wrote on 2022-10-16, 07:51:

Partition ID is definitely different for fat12/16 & fat32

Yes, right, but that's not what I meant to say. 😅

In the past, different IDs for plain FAT existed.
Partly also because they were different (FAT16, FAT16B, FAT16/VFAT).

The FAT of Atari TOS earlier than 1.04 wasn't completely MS-DOS compatible, for example.

That's why I thought that different DOSes used different FAT32 IDs, maybe, and this prevents booting.

https://en.wikipedia.org/wiki/Partition_type# … f_partition_IDs

Jo22 wrote on 2022-10-16, 08:37:

Yes, right, but that's not what I meant to say. 😅 […]
Show full quote

weedeewee wrote on 2022-10-16, 07:51:

Partition ID is definitely different for fat12/16 & fat32

Yes, right, but that's not what I meant to say. 😅

In the past, different IDs for plain FAT existed.
Partly also because they were different (FAT16, FAT16B, FAT16/VFAT).

The FAT of Atari TOS earlier than 1.04 wasn't completely MS-DOS compatible, for example.

That's why I thought that different DOSes used different FAT32 IDs, maybe, and this prevents booting.

https://en.wikipedia.org/wiki/Partition_type# … f_partition_IDs

Yeah, there are different partition IDs for FAT16/FAT32 to distinguish whether the disk/partition should be accessed via CHS or LBA.

I remember an old caveat, that if the disk contains a 0x05 extended partition, it'll almost always be considered a CHS drive by the OS regardless of BIOS setting, and in some cases, even BIOS will report the drive as 8.4GB max. I suppose that was to ensure compatibility with OSes that predate LBA as mixing LBA and CHS accesses could corrupt data in some cases.

I don't think the filesystem ID matters in this case. It seems to be more a FAT32-specific issue with the MS-DOS/ROM-DOS boot code, whereas with PTS-DOS 32 it is working perfectly fine under all circumstances. On the other hand, FreeDOS kernel can be chainloaded just fine by GRUB4DOS under all circumstances as well.

According to a ROM-DOS manual that I could find, the ROM-DOS.SYS is the kernel and it would be copied as IBMBIO.COM via SYS command, but IBMDOS.COM doesn't seem to be among the files initially present on the boot medium so I wonder if it was created on-site by SYS command.

Additionally, later GRUB4DOS added "msdos" and "pcdos" arguments meant to boot the DOS kernel files directly, but so far I haven't gotten it working at all. None could be loaded this way (including PTS-DOS 32). ROM-DOS.SYS only managed to reach "0123" (it should output "0123456" before showing the starting output) whereas IO.SYS doesn't show any visible output (but I presume it got stuck at the same stage as ROM-DOS).

A bump on this. I took out the boot sector dumps from the VM snapshots, for both FAT16 and FAT32. On the surface (looking at it using a hex editor), it seems the generated boot codes for FAT16 and FAT32 are very different.

Especially with ROM-DOS 7.10. From the signature it seems to be using ROM-DOS 6.22's boot code (DLDOS622) when installing to a FAT16 partition. If installing to a FAT32 partition, the boot code will have a signature for ROM-DOS 7.10 (DLDOS710). This significant difference might be the reason why ROM-DOS and MS-DOS could coexist on a FAT16 partition, but not on a FAT32 one.

Signature-wise, MS-DOS doesn't appear to differ much with FAT16 or FAT32. Both dumps use "MSWIN4.1" as signature.

This is all I could know with just a hex editor. To look further I'll need to use something like HIEW for a disassembled output.

Thanks for the feedback, good luck! 🙂🤞