Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

YSDDT 0.1.2 (DOS Toolkit for Working with Disks & Partitions) (Announce)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 02.10.2025, 01:05
(edited by bretjohn on 02.10.2025, 01:32)

> > 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.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22747 Postings in 2119 Threads, 402 registered users, 144 users online (0 registered, 144 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum