# Calculating free disk space

I use allocation information (bdos 1bh) to calculate free disk space:

(Free clusters * Sector Size) * Sectors per cluster
Is this the way to go?

Login or register to post comments

In basic it is CALL DSKF(0) for drive 1, but I guess that's not what you are asking for

If drive name is valid, then the only way above simple calculation could produce an incorrect result, is if that BDOS call produces incorrect output itself.

What's your doubt here? Whether that BDOS call can be relied upon to work as specified?

TheKid wrote:

In basic it is CALL DSKF(0) for drive 1, but I guess that's not what you are asking for

No, PRINT dskf(x), where x is the drive number (1=A, 2=B etc) if x is 0, then it is the current drive.

You are right, a little mistake it is indeed PRINT instead of CALL

The basic function DSKF(drive) displays the free clusters on disk, not the free disk space. The BDOS function "Get allocation information" returns:
DE = Total clusters on disk
HL = Free clusters on disk

On a 2DD, 9 sectors disk, there is 720kb available. However, minus the boot sector, fat and dir there is 713kb available because it takes 14 sectors (14 * 512 bytes per sector = 7 kb). Therefore, 713 is the value of total clusters on a 2DD disk.

There are two files on a disk (no hidden files): one file of 332 bytes and one file of 2.000 bytes.
Why the free space on disk + file size1 + file size2 doesn't match the free clusters size? What am I missing?

The file size is calculated by the size property of a dir entry (byte 28, 29, 30, 31).

Total clusters 713 = 730.112 bytes
Free clusters 710 = 727.040 bytes

Free space on disk = 632.640 bytes
File 1 332 bytes
File 2 2.000 bytes

The basic function DSKF(drive) displays the free clusters on disk, not the free disk space. The BDOS function "Get allocation information" returns:
DE = Total clusters on disk
HL = Free clusters on disk

On a 2DD, 9 sectors disk, there is 720kb available. However, minus the boot sector, fat and dir there is 713kb available because it takes 14 sectors (14 * 512 bytes per sector = 7 kb). Therefore, 713 is the value of total clusters on a 2DD disk.

There are two files on a disk (no hidden files): one file of 332 bytes and one file of 2.000 bytes.
Why the free space on disk + file size1 + file size2 doesn't match the free clusters size? What am I missing?

The file size is calculated by the size property of a dir entry (byte 28, 29, 30, 31).

Total clusters 713 = 730.112 bytes
Free clusters 710 = 727.040 bytes

Free space on disk = 632.640 bytes
File 1 332 bytes
File 2 2.000 bytes

Bit Addict wrote:

There are two files on a disk (no hidden files): one file of 332 bytes and one file of 2.000 bytes.
Why the free space on disk + file size1 + file size2 doesn't match the free clusters size? What am I missing?

On FAT-formatted disks, space is allocated in multiples of the cluster size. In your example:

A file with size 0 takes up a directory entry, but no disk space (0 allocated clusters).
A file with size 332 occupies a single cluster (=1024 bytes in this case).
A file with size 2000 occupies 2 clusters (=2048 bytes in this case).

So if you start with a freshly formatted disk (713K free) and write 2 files of 332 and 2000 bytes, then 1+2=3 of those 713 clusters will be occupied, and 710 should be left. And that "710" is the number dskf(x) and BDOS function should return.
If not, probably means you've got some more (hidden?) files on disk, or the disk is corrupted in one way or another.

As for file totals, MSX-DOS may report something like 2332 bytes in 2 files, 710K left. So total of file sizes = info from directory entries added, free space = derived from remaining clusters.

Perhaps a little confusing, but a non-issue imho as long as you understand what's being reported & how it's counted.

And the other way around: if you have 10 files of 50 bytes each on a disk (=10 clusters occupied), would you want MSX-DOS to report that as "10KB in 10 files" ? More confusing than adding the lengths from directory entries, I think.

Thanks. A file can indeed take multiple clusters. I have to take the cluster size into account to match the values, not only the file size.