Hi all... > I could run tests with freedos-emm and umbpci. I tried some cross-use of > drivers but those that I tested did not run at all :(
DR DOS EMM386 once worked for me, but later, when FreeDOS EMM386 had all needed features, I stopped using it. I do have a config with MS HIMEM and EMM386, though: The old versions which came with my Win3.1 are more or less okay but the FreeDOS versions are better for my needs. Newer versions of MS HIMEM / EMM386, e.g. from Win9x, probably work as well? For SMARTDRV, you should use the /L (load outside UMB) option and disable delayed writes, though. Because SMARTDRV (newer than MS DOS 4 versions, that is) hooks the block device drivers in evil ways, I would not generally assume it to run stable in FreeDOS. > All tests got down to ONLY this umb+udma is very slow (almost the same > as no udma). Only umb and *everything* loaded low is just the same. The > real prblem is that without DOS=UMB, I cannot access umb at all. This would be VERY strange. So you use DOS=UMB and explicitly load all drivers low, verified with MEM /c that UMBs are actually empty (you can even use EMM386 X=c800-efff to force to zero size to reach that) and you STILL get slow UDMA? At least it is ONLY UDMA which gets slow. "Almost the same as no UDMA" could mean that the UDMA driver decides that it should disable itself - did you get any messages about that on screen? Did it make a difference whether you load UDMA before EMM386 or after EMM386 (the latter being the normal way), in combination with using or not using the VDS option of EMM386? How much of the problem was left after you enabled output-overlap mode (very clever mode :-)) of UDMA? In spite of all UDMA problems, if no other slowdown happens (e.g. DOS=NOUMB is as fast as DOS=UMB if you do both tests without UDMA), we at least know WHERE we have to look for the problem. > Aha! so if buffers are in HMA, UMDA cannot use them and they have to be > copied to/from. It looks like this copy is problem. Buffers are only used for access which is cached by buffers, and the copy between LOW DOS RAM and HMA should be very fast, so the speed problem is small. On the other hand, as said, having many buffers can make speed better, so even if there is a small potential speed problem, you should still use DOS=HIGH. If you disagree, use DOS=LOW or use BUFFERS=-1 (one of the buffers is always low, and -1 forcably limits the amount of buffers to a non-clever amount of 1, BUT loading a disk cache might compensate the lack of BUFFERS). One possible problem: Accessing the HMA can require A20 switches which can be slow. But on the other hand, with DOS=HIGH ALL calls to the DOS kernel require the A20 to be on (and possibly switched to on especially for that call). Luckily there are only few places where the A20 is explicitly switched OFF, so most of the time, the A20 just is-and-stays on. It might be worth testing to try with an HIMEM with the compile- time-option "ignore all requests to switch A20 off" compiled in. Note that FreeDOS EMM386 (according to comments WinNT does the same) already blocks all requests to switch A20 off before they reach HIMEM. To compare, MS EMM386 (the Win3.1 one, roughly as old as the MS DOS 6 one) does process requests to switch the A20 by mapping - it flips between two versions of the page map for the first 4 MB, one of which has an HMA and the other one is in "simulate A20 being off" style which is required for some weird EXEPACK stubs. Because FreeDOS EMM386 does not actually disable A20, EXEPACKed programs require the use of LOADFIX in FreeDOS (which, for some STRANGE and UNKNOWN reason is not compiled into the default FreeCOM command.com and is only present in the non-XMS-swap one). In other words: PLEASE compile LOADFIX into FreeCOM or provide a stand- alone LOADFIX.COM ... For now, you can use LOADHIGH to get similar effects than with LOADFIX, but LOADHIGH requires DOS=UMB and some UMBs. > Could we have a specila version of the kernel (or an extra parameter) > with BUFFERS kept LOW? That would be possible but would neither be much faster nor be a good idea, as it uses more low DOS RAM. We could even have BUFFERS in UMBs. > Memory moving is so slow? As I know memory moving should be fast. > Or it's relate to V86 mode or this kind of stuff? Memory moving to/from HMA is quite fast, as is moving inside low RAM. Enabling / disabling HMA (A20) can take time, but A20 is usually on most of the time anyway, and as said, FreeDOS EMM386 even blocks attempts to switch A20 off. MS EMM386 instead provides a fast A20 simulation created by page mapping. Things which can be slow in V86 mode (only EMM386 and other protected mode environments activate V86 mode for DOS: UMBPCI does not use V86 mode) are IRQs and access to trapped I/O ports (EMM386 traps access to the old PC DMA controller to redirect DMA access to UMBs to where the RAM which is mapped to the UMBs actually is hardware-wise, which can HOPEFULLY be anywhere in 4 GB range, otherwise EMM386 probably just takes care that the UMB RAM is taken from RAM which is in the first 4 MB hardware-wise). The IRQ speed can be improved by using some Pentium features, and Win9x EMM386 and DR DOS EMM386 might use that and might be a bit faster that way. Note that access to UDMA DMA controllers (which I believe to be not the same as the normal DMA controllers) is not trapped by EMM386. So UDMA access to UMBs is not automatically made working. Instead, the UDMA driver has to explicitly ask the EMM386 for advice, which it can do with the VDS interface (EMM386 VDS option enables that). Sorry, that is a quite long mail. I hope it is useful to inspire tests. 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
