DOS ain't dead

> > 19-Aug-2025
> >
> > Bad news! Author Jack Ellis was disconnected from Internet
> > due to personal health reason, since his email stop working,
> > there's no way to contact him. I wish sometimes later he can
> > contact me when back online.

Bad news indeed :-o Best wishes for Jack, I hope he gets well soon!

> I don't personally see the point of using his
> closed source drivers, and now that the BIOS/CSM is long dead, probably few
> besides us even care.

I still use his XHDD driver than can handle VDMA problem on my GB P67 MB, older versions of UDMA/UIDE don't work in V86 mode properly (don't have boot mode) so I can't use them.

---
DOS gives me freedom to unlimited HW access.

> It also says this:
>
> > 19-Aug-2025
> >
> > Bad news! Author Jack Ellis was disconnected from Internet
> > due to personal health reason, since his email stop working,
> > there's no way to contact him. I wish sometimes later he can
> > contact me when back online.
>
> But I don't recommend interacting with him.

Reading Johnson's message, you might think it's something relatively recent, but it's been almost three years since then. As someone who interacted with Jack quite a bit, I doubt he is still in this world.

---
Glory to God for all things

> > It depends on whether you're talking about DOS in general or FreeDOS
> > specifically.
>
> It is more about the DOS most likely using the BIOS to access the hard
> disk. A EDD3 specification draft (you find it under the name
> d1572r3-EDD3.pdf) states for the non-LBA access functions that "sector
> sizes shall be exactly 512 bytes". Albeit this is a draft, I never
> encountered a different sector size (for hard disks!). I am not sure what
> the situation regarding the extended disk access routines INT13.4x is. At
> least INT13.48 seems to expose the physical geometry of the disk. The
> document makes no statement regarding sector size for these functions. So
> it MIGHT be that these functions work on the physical sector size of the
> hard disk, but it MIGHT also be that there is a 512-byte emulation
> involved. For CDs the document clearly states that the sector size is 2048
> bytes: "INT 13 Functions 41h-49h shall access the CD or DVD using
> non-emulated sector LBA’s in the native sector size
> of the CD or DVD". Regarding the draft 1572, I was not able to find out
> whether there was an official release of this document.
>
> So far for the INT13. Might be a different story when using custom DOS
> device drivers interacting on a more direct way with the hardware. How does
> your USBDRIVE handle this? Is it able to handle non-512 BPS devices? And if
> it is, how does it present such kind of device to the operating system?

USBDrive does several things. It is important to remember that USBDRIVE is installed as a TSR _after_ the system has booted so cannot change things that are configured while booting. This includes the maximum bytes-per-sector. The maximum bytes per sector value for DOS is stored in the List of Lists (LOL). The way MS-DOS works is that the default/original value stored in the LOL is 128 (it's not even 512). As MS-DOS is booting, it changes this value dynamically as it detects disks/partitions and assigns drive letters. Most of the time, of course, it changes from 128 to 512. That value also affects other things configured while booting, such as how BUFFERS work.

In MS-DOS, the disks detected and assigned drive letters during booting include any "special" disk drivers installed in CONFIG.SYS which can include things like RAM disks. I install a RAM disk in CONFIG.SYS which has a 2k sector size and MS-DOS handles the rest of the details automatically. You can also modify the DOS kernel to change the default value of 128 to something else (like 2048), which I have done but find that installing a RAM disk is easier. The RAM disk installation will fail if it's using a DOS that's incompatible with larger sectors.

As part of the boot sector of all drives (even if they aren't bootable they still have a boot sector) there is a BIOS Parameter Block (BPB) structure that contains the bytes-per-sector value for the disk. The BPB is on the disk and is also transferred back and forth through the disk device driver mechanism that DOS uses to access and control disks. So the actual bytes-per-sector size of a disk is not "hidden" and there really isn't a _valid_ reason to assume it's always 512.

USBDrive supports "plug and play" of disks, so while installing USBDrive looks at and remembers the value stored in the LOL and won't assign a drive letter to a disk with a sector size that the DOS can't support. But it still allows INT 13h functions to access the disk directly. This would allow a special disk driver (that bypasses the kernel) to access the disk. Something similar happens if USBDrive detects an incompatible file system on the disk (e.g., if it detects FAT32 on a disk where the DOS only supports FAT12/FAT16 or detects exFAT on a disk since AFAIK there is no DOS at all that natively supports exFAT). USBDrive always allows INT 13h access to all disks even if the aren't assigned any drive letters.

To assign drive letters, USBDrive fills in various internal DOS tables, some of which include the bytes-per-sector value. In addition to the BIOS Parameter Block (BPB) and device driver functions, there is also a data structure in DOS called the Disk Parameter Block which contains the bytes-per-sector value for the disk.

The INT 13h extended functions (41h-49h) also allow access to large disks and disks with large sectors sizes, and return data that the "regular" INT 13h functions don't include. USBDrive supports both the original and extended INT 13h functions.

I've also experimented with mounting CD/DVD/BD's (which all natively have 2k sector sizes). I've successfully mounted a USB-attached DVD-RAM (with a 2k sector size) formatted with FAT32 _natively_ into MS-DOS and was able to read and write (much like a REALLY big floppy drive). I formatted the DVD-RAM with FAT32 using Windows (I think it was an older version of Windows since I'm not sure newer versions will do it, and I don't think there's a DOS FORMAT anywhere that will do it, and DVD-RAM media is really hard to find these days). I'm also trying to experiment with formatting "regular" CD/DVD/BD's (not DVD-RAMs) with FAT32 and maybe even dividing them into partitions to see if that will work. I don't know if something like that will be very useful, but I think it should be possible. The way I insert data into the DOS tables the kernel doesn't know how the disk is actually being accessed.

MS-DOS v4 to v6 (and v7 in CHS mode) have to know the CHS geometry, and it may have to match what's found in MBR/EPBR/BPB.

> Btw I tried to manually create a primary partition that started at CHS 0,
> 8, 1 (LBA 504 that is 4k aligned) and CHS 1, 0, 1 but PQ magic still
> complained with error 105 or 110, so I don't try fit CHS alignment...

For my tests and the bootimg/partdisk.asm script I found that the most compatible thing is to start primary and logical partitions on a head boundary (CHS x:y:1), start extended partitions on a cylinder boundary (CHS x:0:1), and end all partitions on a cylinder boundary (CHS x:H-1:S).

Quoting from my sources: https://hg.pushbx.org/ecm/bootimg/file/340b7e5286d4/partdisk.asm#l51

> Size is rounded up to the next full sector. Further, partitions are always placed so that their start is on a head boundary (for primary and logical partitions) or so that their start is on a cylinder boundary (for extended partitions). Moreover, the size is always rounded up so that any partition ends on a cylinder boundary. (Extended partitions of type 5 must start on a cylinder boundary for MS-DOS v4 to v7 at least because their UPBs contain an amount of hidden sector within the innermost extended partition and a cylinder adjustment that is added in only after calculating the CHS from the LBA number.)

---
l