Hi, combined answer... > EMM386 doesn't support VDS double-buffering, and reports that when > queried. There is address translation and boundary report function support > only. VDS implementation is not a part of the equation on transfer speed > and slow/fast VDS is not an issue.
> I know that Freedos won't read data directly into a UMB > destination; these data are read single-sectorwise through a buffer > loaded in low RAM... > > This is what made me think that the UDMA driver could have decided that > > UDMA is not possible for some reason caused by enabling UMBs... But Jack said: UDMA never takes back the decision to enable, so the slowdown - if caused by an UMB related decision of UDMA - would have to go away if you load UDMA BEFORE EMM386. > That is why I wish that I could move ONLY the buffers to low memory, but > as was said here today, this seems too complicated... It is not overly complicated, but as Tom said: > BUFFERS= are accessed (and used) only for single sector transfers. For example to cache directory or FAT reads, that is. > > part of the problem. AND Jack, I think the 47 seconds were FREEDOS HIMEM > > version 3.10, not MS HIMEM. > interesting 'I think' Because: > Thanks to Jack Ellis, he did help me to test HIMEM 3.10 and FDXMS 0.94... (said Johnson) ... and 3.10 is the same version as current FreeDOS HIMEM. > Jack needs the absolute adress to do UDMA transfer to XMS. Yes. But I had an argument with Jack about whether or not and when to lock the XMS which is used in my CACHE. Off-topic. > > This means that "loadhigh xcopy" will be slower than "xcopy"... > and you'll get single sector transfer's - which IS slow. Yes - but most people neither loadhigh xcopy nor rawspeed nor rawread. So something else which actively uses UMBs might cause the slowdown. > DOS=HIGH and DOS=UMB won't make a difference from the BUFFERS point of view Feels the same for me, but Alain reports "DOS=UMB makes speed test results with UDMA so slow as if UDMA would not be loaded". Strange. > if you are talking about measured ~2MB/sec (Alains major complain), > XMS transfer speed is entirely irrelevant... Agreed... > VDS is fast in absolute terms - about as fast as 'lock XMS buffer'... Interesting to know, but I am no VDS expert. Tom and Jack could discuss it. > > problems between UDMA and the UMB driver. Which can for example mean > > "EMM386 of FreeDOS has slow VDS". > unlikely to be relevant. Well SOMETHING should cause the problem. Alain does not think that a certain disk related driver is caching things in UMB, but still he does get that strange slowdown (you have to ask him for details). > rawspeed came from somewhere else, I still don't know what it does, > and scince it gave very inconsistent results, I wrote RAWREAD where I > know what it does, and source is available. Very good point. But it is still interesting that rawspeed is able to get slowed down by UMB presence. Maybe rawspeed itself allocates buffers in UMBs, that would be stupid but possible. So: use RAWREAD! > If UDMA2 loads first, EMM386/UMBPCI are expected NOT to "re-map" > or otherwise change its address! Not the address of UDMA - but after EMM386 is loaded, UMBs will be available, other programs can start using them, and the buffers of the other programs can be in UMB which can be a speed problem...? > /L stops UltraDMA to/from any physical address above > 0009FFFFh (except those for the "local buffer" in XMS memory), which > is required to use UMBPCI. If /L was NOT used, the drivers allow > UltraDMA to ANY physical address... So the /L switch has no effect on where UDMA itself is in RAM? And if /L is NOT used, UDMA informs EMM386 about all transfers above 9ffffh, I assume, to avoid possible mapping problems? > Finally, "A20" address-line switching for HMA access IS NOT REQUIRED, > if an UltraDMA driver is loaded! ALL my UltraDMA drivers PERMANENTLY > ENABLE the "A20" line during driver-init... ... which leads to the LOADFIX problem. Some ancient (MS) programs can do some pointer tricks which underflow to ffff:xxxx if the program is loaded to the first 64k. On 8086, ffff:xxxx is just an alias for 0000:yyyy and everything is fine. This means: EITHER you must disable the A20 before you start those crappy MS programs OR you must load them with LOADFIX (which keeps them out of the first 64k). So because UDMA - and actually FreeDOS EMM386 as well - makes it impossible to disable the A20, you have to use LOADFIX. The other way round, if you do have LOADFIX, you can ignore the whole ancient A20 story and keep the A20 on all the time :-). If your first 64k are already full with other stuff, you never need LOADFIX anyway... And if you have an 8086, which has no A20 (A20 is always off), you need no loadfix either. Which is why it is VERY strange that only the non-XMS-swap version of FreeCOM (for 8086) has LOADFIX (which is never needed on 8086). The "disable A20 between start-of-program and first int 21 call after that" logics are, by the way, part of the FreeDOS kernel. No user command. > In other words: PLEASE compile LOADFIX into FreeCOM... Jeremy: Nobody ever found out why only non-XMS-swap FreeCOM has LOADFIX, or actually only Steffen could tell. But he is quite GONE. Too much work, too much stress with neighbours or landlord or whatever, dunno. So you can commit to CVS whatever you think should be in CVS. And you can indeed do a feature-freeze to release new stable versions from time to time yourself, if you ask me. You are de-facto FreeCOM maintainer, and one of few people who set up the proper compile environment. Erwin can compile FreeCOM, too (which leads to the question: where is IMRE?). Eric ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
