Can't boot XT from Hard Drive.

[Bret]

I'm setting up several different machines and different versions of DOS with PCem v17 under Windows 10, but can't can't get the 8088/XT to boot from a hard drive (VHD). I can get the XT to boot from a floppy and see the hard drive just fine so I know it's mounting correctly, but for some reason it won't boot. I just get a "." appearing in the upper left corner of the window and then nothing else happens. I use the exact same VHD for other machine configurations in PCem (from a 286 on up) and also in other emulators, so I know it's a valid boot image.

Here's the configuration file (of course, I eject the floppy when I try to boot from the hard drive):

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 0
model = ibmxt
cpu_manufacturer = 0
cpu = 5
cpu_use_dynarec = 0
cpu_waitstates = 0
gfxcard = oti067
video_speed = 0
sndcard = adlib
cpu_speed = 4
has_fpu = 0
disc_a = D:\bretj\Documents\Virtual Machines\Floppy Boot Images\MS-DOS 3.20 360.img
disc_b =
hdd_controller = mfm_xebec
mem_size = 640
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 2
cdrom_path =
hdc_sectors = 17
hdc_heads = 4
hdc_cylinders = 615
hdc_fn = D:\bretj\Documents\Virtual Machines\VHDs\Multi-DOS 20MB Type 2.vhd
hdd_sectors = 17
hdd_heads = 4
hdd_cylinders = 615
hdd_fn = D:\bretj\Documents\Virtual Machines\VHDs\Multi-DOS Common Boot 20MB Type 2.vhd
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn =
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn =
drive_a_type = 1
drive_b_type = 1
bpb_disable = 0
joystick_type = 0
mouse_type = 0
enable_sync = 1
netcard = ne2000
lpt1_device = none
vid_resize = 0
video_fullscreen_scale = 0
video_fullscreen_first = 1
fpu = 8087
zip_channel = -1
hdg_sectors = 0
hdg_heads = 0
hdg_cylinders = 0
hdg_fn =
hdh_sectors = 0
hdh_heads = 0
hdh_cylinders = 0
hdh_fn =
hdi_sectors = 0
hdi_heads = 0
hdi_cylinders = 0
hdi_fn =
cd_speed = 1
cd_model = pcemcd

[Joysticks]
joystick_0_nr = 0
joystick_1_nr = 0

[SDL2]
screenshot_format = png
screenshot_flash = 1
custom_width = 640
custom_height = 480
fullscreen = 0
fullscreen_mode = 0
scale = 1
scale_mode = 1
vsync = 0
focus_dim = 1
alternative_update_lock = 0
render_driver = auto

[GL3]
input_scale = 1.000000
input_stretch = 0
shader_refresh_rate = 0.000000

[GL3 Shaders]
shaders = 0

[ruben_balea]

Multi-DOS Common Boot Are you using a bootloader? because it may use 286 instructions.
Otherwise everything seems correct, it works for me with the same settings and hard drive images of the same size, I "fdisked" and formatted the hard drive using an MS-DOS 6.22 boot disk and then booted from the hard drive with no problem.

[Bret]

I do use a Multi-Boot program (System Commander) with the higher level CPU's, and it does require a 286+ CPU. But in the experiments I just used a single DOS without the boot manager.

I finally figured out a way to get it to boot, which was to make the disk a Type 1 (10 MB) instead of a Type 2 (20 MB). I know the original XT''s came with 10 MB hard drives, but it doesn't make any sense why it will recognize a 20 MB drive just fine but not boot from it. And as you say it seems to boot for you with a 20 MB disk.

Anyway, I can work with this configuration even though it's not what I wanted to do.

[Arjen42]

MS-DOS 3.20 max supported partition size is 16 MB. Also it does not support extended partitions with logical volumes. So you cannot create a D: drive for the remaining disk space.

MS-DOS 3.30 max supported partition size is 32 MB and it supports extended partitions with logical volumes. So you can create a D: drive for the remaining disk space.

MS-DOS 3.31 max supported partition size is 2GB.

MS-DOS 3.20 fdisk works differently than fdisk of newer versions. One thing is that after creating a new partition it appears to be already formatted, however I'm not sure if this done entirely correctly.

Also if the geometry in the MBR does not correspond to the geometry in the BIOS you cannot boot from it, but otherwise the disk is accessible because MS-DOS does not use the geometry.

[Arjen42]

MS-DOS 3.20 max supported partition size is 16 MB.

I did some testing, and apparently MS-DOS 3.20 does support partition sizes up to 32 MB. So I guess the 16 MB limit applies to FAT-12 supported in MS-DOS 2.x and the 32 MB limiet applies to FAT-16. The difference between the 16 MB and 32 MB can be explained with larger cluster sizes in FAT-12, but I need to verify that.

I tested with the following: IBM PC/XT, 20 MB type 2 HD, IBM PC-DOS 3.20. In the earlier version fdisk displays size in cylinders instead of MB. Same goes for format. I did use an existing disk image without zeroing the MBR. Previously used by PC-DOS 3.30. But I suspect the geometry issues do not apply with BIOS's this early.

[Arjen42]

I did some more testing with PC-DOS 2.10. Formatting 20 MB works just fine with this version. And I checked Wikipedia, The limit of FAT-12 is 32 MB (with 8kB cluster size) as well.

[ruben_balea]

I suspect some of those limits were not always real, it just had to be the largest hard drive size that existed when those operating systems versions came out, I remember MS-DOS 2.something shipped with the Sinclair PC200 did a proper install on another computer with a 40MB Conner CP3044 drive.

[Bret]

Thanks for all the testing! In the XT class machines, there is no BIOS setup to "memorize" the disk geometries like there is with newer BIOSs. Everything is in the MFM/RLL controller and it never shows you what it's doing. I remember with at least some of the early controllers you could get into DEBUG and do a "G=C800:5" and it would run a hard drive setup program.

In my case, I'm not using any logical partitions at all. I just have two separate VHDs each with a single primary partition, so there's not problem getting both a C: and a D: in any version of DOS that supports hard drives. I'm also well aware of the 32MB limit in early versions of DOS (both for FAT12 and FAT16). When I'm messing with old DOS versions I keep everything under 32 MB.

Nonetheless, even though I've figured a way around the problem, i still would like to know why it won't boot from the 20 MB disk. It reads the data from the 20 MB disk just fine, so the system is "happy enough" with the geometry to read it even though it won't boot from it. I suspect it's somehow related to geometry, but I can't imagine what the problem would be, and others don't seem to be having the same issue.

[ruben_balea]

Inside PCem using the DTC5150X controller BIOS commands is useless, at most it will delete the contents of the drive but nothing else, formatting the drive at low level is useless as PCem ignores those commands, if you want to split a single drive into two logical drives you must do it with FDISK.
I really don't know what the controller was doing with a real MFM drive to split it into two logical drives, I don't know if it was writing something to some reserved sector of the disk or maybe to an EEPROM.
But the same 20MB hard drive image works fine for me using DTC5150X, Xebec or IDE controllers, it could have been a boot sector or partition table incompatibility with the IBM XT BIOS or the Xebec controller BIOS.

[ruben_balea]

From experience I know that when the PS/2 model 70 "gets angry" (bad CMOS settings or the like) it only supports floppy disks with the PC-DOS boot sector, although the XT does not have a CMOS it may expect to find a boot sector or partition table in a specific format, and maybe not all versions of MS-DOS implemented it correctly, after all when most came out the Xebec controller was already very outdated and maybe they hadn't even checked or taken it into account.

[Arjen42]

I suspect some of those limits were not always real, it just had to be the largest hard drive size that existed when those operating systems versions came out, I remember MS-DOS 2.something shipped with the Sinclair PC200 did a proper install on another computer with a 40MB Conner CP3044 drive.

Early MS-DOS releases where often customized by the OEMs, including IBM. Especially to support non-standard hardware. This eventually evolved into separate drivers that can be loaded when needed.

[Arjen42]

Nonetheless, even though I've figured a way around the problem, i still would like to know why it won't boot from the 20 MB disk. It reads the data from the 20 MB disk just fine, so the system is "happy enough" with the geometry to read it even though it won't boot from it. I suspect it's somehow related to geometry, but I can't imagine what the problem would be, and others don't seem to be having the same issue.

Bootstrapping from a harddisk just works a little differently than just reading files from a FAT filesystem. This also differs from different versions of MS-DOS.

In normal file I/O the OS searches the (root) directory for the filename to get the first cluster id, then it queries the FAT to get the other cluster id. After that it reads the clusters from disk. (Converting cluster id's to sector id's is a trivial mathematical procedure.)

During bootstrap from a floppy disk the BIOS reads the first sector (bootsector) which contains information about the floppy geometry and code to load the operating system e.g. IO.SYS and MSDOS.SYS (or IBMBIO.COM and IBMDOS.COM). On early MS-DOS versions those files had to be at the beginning of the disk at exact locations. The loader didn't use the filesystem. (MSDOS.SYS contains the FAT driver.)

Bootstrap from a hard drive is a bit more complicated because partitions and no exact locations. First read the MBR which contains information about geometry, partitions, and boot code, and then the active partition's boot sector which also contains information about the size, the filesystem, and boot code. After that load the operating system.

MS-DOS doesn't use geometry, it let's the controller handle that. But the BIOS does use geometry, but it isn't really good about that. Although it should understand how 20MB type 2 disks work. You might want to try a SCSI controller instead of a MFM controller. However if you swap a disk image between controllers it may be unbootable because of geometry differences, which sounds a bit like your problem. XT-IDE may also work. Not all PC types are compatible with all controller types, and in PCem things that work with real hardware don't always work in the same way.