With your chainloader proposal, I can be confident that there will be a fallback to run the current Grub4DOS in PCem. So I can still do some procrastination before starting to search the supposed bug. I am thinking about how to build a more generic testbed VHD for backward compatibility checks, one which is able to boot to the latest GRLDR on both PCem and VirtualBox. But I also have to sum up the results of my previous experiments before I forget the relevant details.
I kind of want to accept that this boot manager named Grub4DOS, in its current versions, can no longer rely on itself for PC backward compatibility. When saying "backward compatibility", I think of my first computer, which was a Toshiba T1100 laptop running a branded version of DOS 2.11. PC-DOS 2.0 for the IBM XT was the first version to support hard disks up to 32 MiB with FAT12 (type 0x01) file system, assuming a C/H/S = 1023/4/17 geometry. But it was already prepared to support C/H/S = 1023/16/63 geometry if only the starting cylinder was 0 and the maximum cylinder size of the 32 MiB partition just 65. The hard disk space was only available in slots, as multiples of cylinders. One cylinder held 16*63*512 B or 504 KiB < 0.5 MiB, the maximum being 32,760 KiB < 32 MiB.
Then PC-DOS 3.0 introduced a FAT16 (type 0x04) file system that still was limited to 32 MiB. It made FAT12 above 32 cylinders (16 MiB) incompatible by formatting partitions of 33 cylinders and more as FAT16. DOS 3.0 could only be booted from the new file system. This remained unchanged until version PC-DOS 3.2 A dual-boot system can be created, using FDISK to change the active boot partition, if the FAT12 partition starts at cylinder 0 and has a size of at most 32 cylinders. The file type in the partition table then can be changed to 0x11 (hidden), and a new FAT16 partition for PC-DOS 3.0 can be added. Its size, however, will be limited such that it sums up to 65 cylinders together with the existing FAT12 partition. This remains unchanged until MS-DOS 3.31.
So initially, only the first 65 cylinders could hold a bootable partition, but even a third entry in the partition table could be activated for boot if the FAT12 partition was smaller. If it was reduced to 8 MiB (16 cylinders), smaller than the original 10 MiB XT, it could still hold a running Windows 1.04. But then 16 single cylinders would become available that could be made bootable if entered individually, as primary partition, in the partition table in the master boot record. The commands MAP and (not limited to real mode) PARTNEW, according to README_GRUB4DOS.txt, can do this dynamically, simply by directing to an existing logical partition which would be unbootable from within an extended partition.
Those logical partitions inside an extended partition, which serves as a container to fill the forth entry in the partition table, are introduced with DOS 3.3, but still restricted to 32 MiB in size (and to the remaining letters of the alphabet for drive assignment), but make the full 503 MiB VHD accessible. It is DOS 3.31 that can make all the space available as one whole partition, introducing a third file system, FAT16B (type 0x06), for partitions above 32 MiB. DOS 3.31 is also the last version to be limited to the C/H/S = 1023/16/63 geometry. Checks for "backward compatibility", even on such a small VHD, will need to deal with all these file systems and early DOS versions, in addition to (or before) booting modern NTLDR and Grub4DOS.
* * *
0. In other words, and more like a how-to: For backward compatibility tests, create a new 503 MiB fixed-size VHD image named BACKWARD.VHD with C/H/S = 1023/16/63 geometry in PCem. Opened in TinyHexer, it is just a big bag of zeroes with an additional sector that contains a "conectix" string (and a universal identifier, which PCem happily ignores but VirtualBox takes utmost seriously). You can use FDISK of either DOS versions 2.0 to 3.31 to create the boot sector, and the executable code written by David Litton in the upper half still looks identical. Only the 4 * 16 bytes of the partition table at the four last lines, shifted forward by two bytes by the 0x55 0xAA signature, will differ; see full hex dump of the PC-DOS 2.0 MBR:
https://thestarman.p.../mbr/200MBR.htm
https://en.wikipedia...f_partition_IDs
https://en.wikipedia...n_table_entries
1a. Boot from a PC-DOS 2.0 disk. FDISK reports only 1022 cylinders total disk space, assigning index number -1 to the first cylinder and reserving it for the boot manager. Create a DOS partition of only 16 cylinders, starting at number 0, ending at 15, and activate it. Reboot. Enter FORMAT C: /S and COPY *.* C: to transfer the system. Eject the floppy image and reboot. PCem boots to PC-DOS 2.0 from BACKWARD.VHD. The last two lines of the master boot record, which is immediately followed by executable code, now look as follows. The partition created at first occupies the last partition table entry. It starts with the active byte 0x80 as first (offset 0x00). The type is 0x01 (FAT12) as fifth byte (offset 0x04, third on last line):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
02 00 01 0F 3F 0F 01 00 00 00 FF 3E 00 00 55 AA
1b. Hide and deactivate this FAT12 partition:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 55 AA
2a. Boot from a PC-DOS 3.0 disk. Create a DOS partition in FDISK. Maximum available space is 49 cylinders. Enter partition size 33 cylinders starting at 16. Activate new partition 2. Reboot. Enter FORMAT C: /S and COPY *.* C: to transfer the system. Eject the floppy image and reboot. PCem boots to PC-DOS 3.0 from BACKWARD.VHD The partition table now looks as follows. The active byte sits at the same place again, which now designates the FAT16 partition (type 0x04), shifting upward one line the entry that was created first:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA
2b. Unhide the FAT12 partition:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 01 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA
Reboot to PC-DOS 3.0 from BACKWARD.VHD. Run FDISK to activate the first partition. Reboot to PC-DOS 2.0. Run FDISK to activate the second partition. Hide FAT12 partition like in 2a. Reboot to PC-DOS 3.0. This not-so-comfortable multibooting funtionality could directly be extended to DOS 3.31, which again is bootable from a small FAT12 partition, using the third primary partition entry in the table that can be made active. As said, I attempt to achieve even greater booting flexibility using logical partitons and Grub4DOS's MAP and PARTNEW commands.
3a. Boot from a MS-DOS 3.31 disk. FDISK offers to create either a primary or an extended partition which can be at most 973 cylinders in size, from cylinder 49 to 1021, which is just fine. Now FDISK wants to create logical drives. Instead of using the whole space for one large partition, create 16 partitions of only 1 cylinder in size (cylinders 49 to 64, drive letters D: to S:, 504 KiB each); one partition of 32 cylinders, the maximum for FAT12 (drive T: 16 MiB); and one partition of 33 cylinders, the minimum for FAT16 (drive V:). The rest of 892 cylinders then remains for a FAT16B partition (drive V:, 439 MiB) which, as FDISK warns, is inaccessible for older versions including DOS 3.3.
3b. After reboot from MS-DOS 3.31, drive C: is occupied with PC-DOS 3.0 files. When you enter FORMAT D: /S and COPY *.* D: to transfer the system, the disk space is insufficient, but the harder problem is: When you eject the floppy image from drive A:, PCem still reboots to PC-DOS 3.0, of course. The logical drive D: is unbootable because it is not yet directed to from the partition table, which as fourth entry only holds the extended type 0x05 partition, with one line for the third primary partition being left out:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 31 05 0F FF FD F0 C0 00 00 30 F7 0E 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
02 00 11 0F 3F 0F 01 00 00 00 FF 3E 00 00 80 00
01 10 04 0F 3F 30 00 3F 00 00 F0 81 00 00 55 AA
So much for today. The next step involves getting Grub4DOS to run in the testbed defined by this partition table and the logical drives.
Gerolf