Making foreign DOS boot floppies (IBM).

From: Tom Jennings <tomj_at_wps.com>
Date: Tue Apr 13 13:41:37 2004

On Tue, 13 Apr 2004, Fred N. van Kempen wrote:

> The older boot sectors loaded IO.SYS (IBMBIO.COM for PC-DOS) as
> first entry, using the cluster mapping found for the first entry
> in the root directory, and then the same for MSDOS.SYS (IBMDOS.COM
> for PC-DOS) using the second entry in that root directory. I do
> remember there was some level of magic checking- but afaik, they
> took that out fairly quickly.

Umm, it was even simpler than that.

Considered as a string of sectors, the diskette is boot, fat?,
dir?, data. Boot+dir+FAT is a fixed number of sectors, therefore,
on a new, blank diskette the first data sector is N.

The boot loader simply has to load 64K (see below) of data from
the diskette starting at sector N, and jump to 10:0 or whatever
that address is/was.

Copying IO.SYS and MSDOS.SYS sequentially to a newly-formatted
floppy guarenteed that the sectors were contiguous starting with
the first data sector, eg. not scattered around the disk. The
512-byte boot loader didn't have to parse the directory or FAT,
just load sectors starting with N. Filenames only mattered to
FORMAT, SYS and other runtime stuff, not the boot loader.

Boot code that knew about multiple diskette formats (SSSD,
SSDD, DSDD) used the first byte of the first FAT sector to
ID the format, aka the FATID, this determined N, the starting
sector for the boot load.

"64K" isn't a mistake or typo. I've long since forgotten the
constraints on BIOS and MSDOS.SYS size, but at least in DOS
3.x days you were guarenteed that BIOS+MSDOS.SYS < 64K.

(64K being of course the limitation of then-extant DMA chips
address range. Most of the hardware I worked on had the DMA
controller address lines 0 - 15 mapped to CPU physical 0 -
15, and a "page" register selected the upper address bits,
eg. it didn't "segment" like the CPU. I coded my drivers such
that it DMA'd data directly into user space by normalizing the
address to absolute, for requests that didn't cross a module
64K boundary; those that did had the violating sector read into
a BIOS buffer and block-moved, no way around that.)

IBM added non-boot-loader proprietary junk to the boot sector,
including the string "IBM CORP" or something and refused to boot
non-IBM DOS. All the partition stuff got added after I left
the scene. The boot sector used to actually contain BOOT CODE
INSTRUCTIONS, I assume that's no longer the case. Later booters
also learned how to read FATs and dirs and read non-contiguous
IO.SYS and all that.



>
> So, assuming a blank diskette:
>
> 1. Format it with FAT(-12)
> 2. Make *sure* the first two directory entries are blank, which
> includes no volume label being present (== dir entry !)
> 3. Copy those two files over.
> 4. Patch the boot sector.
> 5. Copy COMMAND.COM and any other files.
>
> This has always worked for me. But, yeah, as someone already
> pointed out, it is much easier to just archive bootable images
> of these diskettes :)
>
> --f
>
Received on Tue Apr 13 2004 - 13:41:37 BST