VOGONS


First post, by chartreuse

User metadata
Rank Newbie
Rank
Newbie

Like many other people I've been finding myself annoyed at the 15-30s delay on XT class machines to calculate free disk space on drives >32MB using FAT16 (32k to 64k total clusters). After only finding somewhat janky solutions such as caching the value on shutdown to disk. I decided to tackle the problem myself.

Having heard that the DOS calculation is inefficient due to doing smaller reads and possibly even traversing the file and directory structures as part of its check, I set out to try just calculating the free space my self from the FAT. My approach was simple, load the FAT into RAM and count the number of in-use clusters and subtract that from the total clusters on disk, then populate that back into the Drive Parameter Block field.

I wasn't certain at first if this method would be faster or not, but after getting to the point of scanning the entire fat and counting up the clusters I found that it was a significant improvement over DOS's calculation. On my 8MHz Turbo XT my program was calculating and populating the free cluster count in approximately 1 second, vs 14 seconds for DIR to calculate it. And at 4.77MHz the calculation was performed in under 2 seconds compared with 25s.

The program can be placed into autoexec.bat to pre-populate the free space for any desired disks on the system.

Limitations

The drive being run on must by FAT16, and have 512 bytes per sector (basically all hard drives will meet this).

If a program is run which performs raw disk access (int 25h/26h) such as CHKDSK the value cached by DOS is invalidated (set to FFFF) which means the calculation needs to be performed again. As this program is not a TSR (Yet! I'm working on that) the next time the disk free space is calculated will be done by DOS's slow method, you can manually run FREESP again if you like but running these programs is less common.

This program requires DOS 4 or greater, and has been tested on 5.0 and 6.22, which is where you'd run into this delay in the first place. I've not been able to find documentation on how Compaq DOS 3.31 handles the int 25h system call or how it's DPB is laid out so I'm unable to confirm how this works using it's limited FAT16 large disk support.

The disk space calculation returned by this in my testing always matches that done by DOS itself, but if there's some odd edge case you encounter let me know and I can try to fix it.

The Program

The program is available at https://github.com/ChartreuseK/FREESP in both source code and binary form. You can find the assembled COM file under the Releases section, or you can assemble the source with Borland TASM 2.0 or later.

Usage:

FREESP <A-Z>

Example:

FREESP C

This will pre-calculate free space on the C partition. The drive letter is required, if you want to pre-calculate multiple partitions run the program multiple times in your autoexec.bat

Reply 1 of 8, by debs3759

User metadata
Rank Oldbie
Rank
Oldbie

This is a great little app. I haven't gone through the full source code yet, but have one comment. As it needs tasm (which not everyone has access to), could you provide the .com file as well as source code? Otherwise, nasm or any other free assembler in active development would be better.

If I try it, I'll rewrite it for nasm, as that is the assembler I use. That's a trivial conversion, as I it won't need many changes. I've downloaded it already to take a proper look at. Might give me some tips for when I get back to working on my own OS code 😀

See my graphics card database at www.gpuzoo.com
Constantly being worked on. Feel free to message me with any corrections or details of cards you would like me to research and add.

Reply 2 of 8, by chartreuse

User metadata
Rank Newbie
Rank
Newbie
debs3759 wrote on 2021-01-20, 01:47:

This is a great little app. I haven't gone through the full source code yet, but have one comment. As it needs tasm (which not everyone has access to), could you provide the .com file as well as source code? Otherwise, nasm or any other free assembler in active development would be better.

If I try it, I'll rewrite it for nasm, as that is the assembler I use. That's a trivial conversion, as I it won't need many changes. I've downloaded it already to take a proper look at. Might give me some tips for when I get back to working on my own OS code 😀

There's a pre-assembled COM file available under the Releases section on github. https://github.com/ChartreuseK/FREESP/releases I mentioned that in my original post, but Github doesn't do the best job at making it visible. Shouldn't take much to port this to NASM, just the local labels and possibly the PROC/ARGS delaration, though the later can just be turned into straight BP offsets for the parameters.

Reply 3 of 8, by debs3759

User metadata
Rank Oldbie
Rank
Oldbie

I missed that, thanks.

See my graphics card database at www.gpuzoo.com
Constantly being worked on. Feel free to message me with any corrections or details of cards you would like me to research and add.

Reply 4 of 8, by chartreuse

User metadata
Rank Newbie
Rank
Newbie

Took some learning into writing TSRs and some thought as to how to implement it, but I've now got FREESP working in TSR form as FREESPT.

Source code can again be found at: https://github.com/ChartreuseK/FREESP
And pre-assembled COM files at: https://github.com/ChartreuseK/FREESP/releases

The TSR hooks int 21h and if the call (AH) is 36h (Get Free Disk Space), which is the DOS call responsible for the long delays. My code intercepts this call and if the free cluster count is invalid/unknown then it will quickly run itself and populate that value before passing the call along to the original handler. To save memory, and to not overcomplicate things by looking for blocks of free memory while another application is running, this version uses only a 512 byte buffer for reading the FAT. This ended up being only a fraction slower than the main FREESP which uses a 64kB buffer, but this allows the TSR to take up only 1,264 bytes of memory while it is loaded, and I'll look into reducing this later if I can. Instead of a calculation when freespt is run for the first time, the free space calculation is now performed the first time it is needed. So the first DIR call will be slightly slower by about a second on an XT. But this is still significantly faster than the 14-25 seconds that DOS's call uses. This TSR version also accepts a list of drives to monitor so one instance can handle up to 18 drives.

C:\> FREESPT CDEF

will monitor drives CDEF and handle free space calculations for them. As before these drives all need to be FAT16 drives.

Reply 5 of 8, by digger

User metadata
Rank Oldbie
Rank
Oldbie

Great work, man! 😃 Have you considered trying to integrate this into FreeDOS and offering a pull request upstream? I'm sure people would love to have this built-in.

Reply 6 of 8, by chartreuse

User metadata
Rank Newbie
Rank
Newbie

Alright, fixed a few bugs in FREESP and FREESPT with the help of some VCF forum members. One major one being that FREESPT wasn't working quite right under COMMAND.COM since I'd been testing under 4DOS for most of the development and it does its calls in a slightly different order. V0.4 fixes that along with some issues with the default drive, and FAT16 detection on some drive setups.

https://github.com/ChartreuseK/FREESP/releases/tag/v0.4

Reply 7 of 8, by Jinxter

User metadata
Rank Member
Rank
Member

I made this video on the FREESP util. https://youtu.be/k71q5CYrlt0

Check out my YouTube channel: Retro Erik https://www.youtube.com/c/RetroErik
My collection: https://retro.hageseter.com