On my PCjr, this cuts the DIR time from 50 seconds to 36 seconds. So, creating partitions that are (for example) 260M, or 518M, or 1.05G, etc., can help because there are only 32K+ entries to slog through instead of 64K+. One way to cut this time down is to create partitions that are just over the size of a power of 2, so that when DOS creates the filesystem, the cluster size doubles and the FAT size halves. (BTW, the very first version of DOS to implement >32M partitions, Compaq DOS 3.31, also has this hang.) Subsequent DIR times are fine, but if an INT 25/26 are performed (absolute disk read/write), the values are reset and boom, a DIR takes a minute again. All this adds up to a 50-second wait when you type DIR on a PCjr for the first time.
On top of all this, DOS's memory structures on a PCjr are always stuck in the first 128K so reading/writing them are very slow. A partition that completely fills the FAT limit (any power of two, such as 128M, 256M, 512M, 1G, 2G) takes the longest to scan because the FAT is near or at the maximum size (~65,000 entries). The larger the FAT, the longer this takes.
Additionally, it updates some internal structures on every iteration of "I found a free cluster" which is very slow due to how DOS is optimized (size, not speed). When I wrote PADD I found out what causes the hang: DOS determines the number of free clusters by scanning the FAT, and to save memory, it does it from the disk itself, sector by sector. I'm not sure FreeDOS eliminates the hang, unless they drastically rewrote how to determine the amount of free clusters. It would be nice to have a recent version of DOS (equivalent to PC DOS 5 or better) so that things like the directory hang could be eliminated.
0 kommentar(er)
