>> Actually, it was a bit surprising to me that I still need a software >> cache ... Well, perhaps the NVIDIA SATA isn't the best fit for DOS. > > DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode. > It would be even slower without UDMA or a software cache. As to > why you need it, it's because (quoting Martin Reiser) "Software > gets slower faster than hardware gets faster". Also known as > "What Intel giveth, Microsoft taketh away."
Intel "giveth" NOTHING, and followeth only "All we want is MONEY!", same as Gates & Co.! In my opinion, absolutely NO excuse for AHCI that a better-written Windows driver could NOT have solved, but for Intel as-always wanting to sell-Sell-SELL new chips! Back in 2008 I asked Lucho how my (then) relatively-new UIDE driver "fared" v.s. Windows, as he ran both DOS and Win/XP, and Lucho replied "You beat THEM 2 months AGO"!! At-least Intel does not "sucketh" like Gates Co. does!! Re: SATA, it does not offer an "IDE compatibility" mode, as it uses all the same commands as IDE. Only its drive cables are different and NOT its "software interface"! AHCI is the one using a totally DIFFERENT command protocol, so it does need and have an "IDE compa- tibility" mode on most mainboards and in most BIOS routines. As I have noted, (A) AHCI is USELESS for DOS, as DOS does "One at a time" I-O and cannot make use of AHCI's much-touted "Native command queuing", and (B) AHCI is RIDICULOUSLY complex, the obvious results of it being designed by a [MISERABLE!] "ANSI committee" which tried to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual! I have REFUSED to implement actual AHCI in UIDE/UIDE2, and I shall do so for as long as "IDE compatibility" mode exists -- I have NO wish to double my drivers' I-O logic and so reduce their cache capacity, "Por NADA!" [for NOTHING], since DOS can never use AHCI queuing! > But actually even DOS software gets slower and bloatier over time. I > hate to bring up DJGPP, one of my favorite things, but take a look at > CC1.EXE (C compiler proper) over the years, quite a difference!!! And > don't forget the differences in x86 families (and software > optimizations) and L1/L2/L3 cache sizes (among a billion other > things). It all heavily varies (and GCC has both pros and cons). Hardware improvements like those you mention will never "hurt" any existing software, only make it faster. As for poor-old "C" com- pilers, which ALSO try to satisfy everybody and end-up satisfying NOBODY, maybe you can understand why I prefer assembly-language! No "constraints" on what code you generate, except your own!! ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
