FreeDOS

[jmetal88]

It's been brought up a few times before, but I still wonder about it from time to time. What would it take to get FreeDOS working on the PCjr? I don't know enough about programming to actually get it working, myself, but I have to think that since the source is available, it would be possible to modify it enough to boot directly on the PCjr. Then with enough time and enthusiasm, perhaps fix a few of the little annoyances that exist when using newer versions of DOS with the PCjr, like the free space recalculation and all that. What do you guys think? Anyone willing to give it a shot?

[Brutman]

I'm on the FreeDOS developers mailing list. Apparently they like mTCP a lot ...

I have not tried FreeDOS on the PCjr. It might "just work" if you use something like JrConfig. But it is probably making assumptions about the machine that the Jr breaks, so it could require a lot of debug.

FreeDOS is kind of a memory pig too. And it's close to PC and MS DOS, but not perfect.

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. But it seems like a lot of work to do, and there are never enough people.

[Trixter]

I was working on my DOS/jrIDE patcher about an hour ago and looked at the FreeDOS boot sector -- I'm not sure where I got my "FreeDOS 360K disk" image from, but the boot sector not only had 386 opcodes in it but also absolutely no strings at all, which means it can't be patched.

Since the source is available, a PCjr-specific version of FreeDOS is likely easy to make for those who have a few hours.

[Trixter]

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.

I'm not sure FreeDOS eliminates the hang, unless they drastically rewrote how to determine the amount of free clusters.

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. 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). The larger the FAT, the longer this takes. 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). 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. All this adds up to a 50-second wait when you type DIR on a PCjr for the first time. 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. (BTW, the very first version of DOS to implement >32M partitions, Compaq DOS 3.31, also has this hang.)

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. 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+. On my PCjr, this cuts the DIR time from 50 seconds to 36 seconds.

What takes 50 seconds on a PCjr takes about 17 seconds when things are working "properly" (an IBM XT with a hard drive controller that uses DMA transfers), just as a point of reference. If DOS's memory structures could somehow be moved out of the first 128K, I have no doubt that it would speed way up, but I think doing so is likely to be different from DOS version to DOS version. Quarterdeck bundled a device driver called DOS-UP.SYS with QEMM 6 and later that did this to free up more low RAM, but it did not work correctly with every version of DOS I remember testing it with.

[Brutman]

That's a great explanation of what is going wrong, but it begs the question - why is the free space value not being cached and maintained?

If I had an algorithm like that I would do it once in a blue moon and then try my best to ensure that I maintained the count correctly so that I would not have to recalculate it. And I'm sure that DOS is doing that to some extent because not every directory listing results in the dreaded pause, but they were either paranoid or sloppy with their accounting and they seem to like to recalculating the value a lot.

That pause is devastating with a network app .. no connection can survive the machine going to sleep for 30 to 50 seconds and not servicing packets.

[Trixter]

That's a great explanation of what is going wrong, but it begs the question - why is the free space value not being cached and maintained?

It is, after the very first time it is requested, but some operations flush it. When an INT 26h (write absolute sector) is performed, it's immediately flushed because DOS has no idea if what you wrote changed the FAT, so it invalidates the cached value. This makes sense to me. What does NOT make sense is that INT 25h (read absolute sector) **ALSO** flushes it which is just idiotic. (I'm reading, I didn't change anything, you stupid DOS!)

If I had an algorithm like that I would do it once in a blue moon and then try my best to ensure that I maintained the count correctly so that I would not have to recalculate it.

Remember that DOS 5.x came out in 1991 when most machines were fast enough that the first DIR took under 5 seconds. And you'll recall that the major focus of all DOS versions from that point forward were trying to free up memory, as it was usual for people to load at least a few TSRs. So the small-but-slow code stayed.

I looked at the leaked MS-DOS 6.0 code last year trying to figure out where the speed hit was and it's just a typical size optimization thing, like (I'm paraphrasing):

Code: Select all

@structure_cache_flush:
  call xxxx:yyyy ; return next free cluster
  call xxxx:zzzz ; update structures
  loop @structure_cache_flush


...where xxxx:yyyy reads from disk sector by sector, and of course xxxx:zzzz does a TON of stuff.

I'm curious how FreeDOS does it, but not curious enough to go actually look :-) I am still working on the DOS patcher, which I'm trying to make as flexible as possible.

[jmetal88]

Well, here are some FreeDOS disks that are supposed to work on PC/XT computers, so maybe these would be suitable for modification:

http://jorisvr.nl/freedos.html

[jmetal88]

I just tried booting the disk I linked to. It displays 'FreeDOS' on the screen, pauses for a couple of seconds, then the whole screen goes really colorful, haha. FreeDOS has evidently hanged at this point, as the boot doesn't try to progress any farther. Don't know if it just needs help finding memory or if it's another issue.

[jmetal88]

UPDATE: I just created a boot disk using the current binaries available from the Sourceforge FreeDOS file archive. It actually looks a lot more promising. I can get it to boot almost all the way through, it will load jrconfig.sys, go into the second boot sequence, then spit back a message that says 'ERROR' and refuse to continue.

[Shaos]

Any news on this topic? I'm interested in running FreeDOS on PCjr