Hi Johnson, Jack, > > You might have noticed that Dima had even MORE memory free even > > though he does NOT use QHIMEM ;-)
> Read my MEM display shown at the end of this E-Mail with my FDCONFIG > and FDAUTO files. I still use V6.22 MS-DOS, not FreeDOS... Ah, you should not use inferior kernels, then you would not have to save memory by tuning memory drivers ;-). And I believe the 620 versus 625 kilobyte problem was because Johnson had accidentally loaded SHSUCDX low and/or had no DOSDATA=UMB. Basically I was just joking. I know that you can save a bit of RAM by using QHIMEM instead of FDXXMS but I wanted to nag you a bit :-p. > So what is WRONG with the /C option?? It WORKS, last I noticed, and > it gives NO problems of which I am aware! Use it and LOVE it, if you > want to SAVE low-memory! The problem is that the default is RELOCATE, not RELOCATE HIGH. So if you, by habit, do "LH SHSUCDX", then it will relocate itself OUT of UMB and INTO low RAM! You have to use the /c option to stop this (so SHSUCDX will stay in UMB) or alternatively stop using LH (so SHSUCDX will relocate itself to UMB). So SHSUCDX is working fine, but in unexpected ways. The way that using and not using the option /c works is somewhat counterintuitive. > And "uhm", there are REASONS why I revised SHSUCDX into SHCDX33A. It > SAVES over 1000 bytes of file space, for my "poor old" 1.4-MB diskettes! Okay, I did not know this. > And its directory buffers are all "aligned" to 4-byte boundaries so > REAL ULTRADMA (not XMS memory nor "PIO mode") can be used... Jason should really dword-align his buffers, then. Did you tell him? > The 2000-byte value above is for V1.0 QHIMEM with all 128 "Handles", > ... 32 "Handles", the above will show 1728 bytes ... > We need to talk about saving 700 BYTES, not just 300! Maybe the FDXXMS also had 128 handles? I do not know. So MAYBE we are talking about saving 700 bytes. > If the FDXMS/FDXXMS writers intended their driver to be "modified", > then WHY did they use its "obscure" assembly-language format... Martin converted FD*XMS* family drivers to GNU Assembler which uses the AT&T syntax. This is quite popular for some platforms, but you are right that on Intel compatible CPU, the Intel Assembler syntax is more popular. I guess Martin uses GAS syntax to make it more clear that FD*XMS* is no longer the same as FD-HIMEM. But there are converters between GAS, NASM and MASM/TASM syntax available on the internet ;-). > As for "questionable sources", they are easily available on the > Internet in a downloadable ZIP file and are FAR from "questionable", > which anyone with Half-a-BRAIN will realize after READING those files! What I was referring to is, quoting Johnson: > Jack did found FDXXMS source code a bit weird and he have some old > MS-EMM386 source code as reference, so he did rewrite the whole thing. (end quote) It is inappropriate to use MS source code unless you have permission from MS to do so. The fact that it is becoming increasingly easy to dig up the sources of MS products from DOS components through the whole DOS up to big parts of Windows itself on the internet does not relate in any way to any implications that it would be legal to download those sources. I recommend that no FreeDOS developer ever looks at those sources... In Germany, a certain amount of reverse engineering (dis- assembly) can be legal if necessary to fix compatibility issues. Still this does not mean that you can use actual source codes from closed source products. Anyway, as Jack repeatedly said that he is not related to FreeDOS anymore, he can decide himself what and how he does. > QHIMEM is a full REWRITE with over 75% of source lines my OWN... You mean it is 25% cut and paste? > QHIMEM uses an 80-byte > low-memory "stub" and Ye Olde Ordinary JUMPS to upper-memory! The > Russians and the well-known software guys could have SAVED 672 > low-memory bytes! (compared to PTS-DOS HIMEM) I know, QHMBOOT is a really great idea. But it should have been written for FDXXMS, not for yet-another-new-QHIMEM. > "By the way", QBUF is a diskette buffer, reserved by QDBOOT for > diskette ISA DMA above 640K, which cannot be handled by UMBPCI... > It is equivalent to the buffer used by the old LOWDMA program. Why don't you use LOWDMA then?? If you use FreeDOS, you do not need QDBOOT or LOWDMA at all, as all disk access can use the low RAM "deblocking buffer" there to solve DMA boundary crossings or UMB access issues. Unless of course you have software which calls int13 directly, as FreeDOS only checks int21/int2f related disk access (unless Jeremy already completed his int13 hook patch). > I guess Eric must enjoy giving up 6032 bytes of low-memory for > FD-HIMEM and FD-EMM386. His choice. I prefer NOT to give up that > much, which is why I use UMBPCI... I absolutely do enjoy using FD HIMEM and FD EMM386, thanks for asking. For software which does not work in vm86 mode, I simply skip loading EMM386. I know that I could then load UMBPCI to get UMBs in real mode, but the "needs raw real mode" software that I have only needs 550k of low RAM, so I simply do not NEED to load drivers to UMBs then. > stackshigh=8,256 Are you sure that you need stacks? > d089 128336 program So you have 128k free UMB space - but why is that useful? Apart from for being proud of having a lot of free memory? > Largest executable program size 625K (639,968 bytes) Quite nice, of course. Eric ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
