Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 22, 2023 at 11:04 AM wrote: > > On May 22, 2023, at 7:03 AM, Rugxulo wrote: > > On Mon, May 15, 2023 at 6:48 PM wrote: > >> > >> Let me show you a MEM print out from my Pentium Pro: > >> > >> NANSI3,536(3K) 0(0K) 3,536(3K) > >> SHSURDRV 400(0K) 0(0K)400(0K) > >> LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > >> CTMOUSE 3,104(3K) 0(0K) 3,104(3K) > > > > NNANSI [sic] can unload, so if you switch to that, all of these can > > optionally be unloaded (if you put them last) to free up memory. Of > > course, SHSURDRV will also unload your whole XMS RAM disk, too. > > Sure. But... > > Even with loading and keeping all that stuff, the system still has 94K free > upper memory and 84K of that is consecutive. > > Unloading those drivers would not free up the 11K of Low memory used by the > Kernel. > It would just free upper memory of which there is plenty. My bad, I didn't notice and assumed it was all in conventional. > The largest executable size is 628K. > Nothing should every require over 600K of low memory to load. I agree that 600 kb is too much for any reasonable app, but it does sometimes happen (esp. games). I think I saw a demoscene app once that also required that much. Very wasteful. (But even DOS compilers aren't that lean and mean. Smartlinking and overlays are a lost art.) > Actually, that MEM print out is outdated for that machine. Just to use up > some more upper memory, > it now loads CWSDMPI at boot. That brings free upper memory down to about > 45K. But if upper memory > gets too low or their are compatibility issues, I’ll stop loading it at boot. It's 32-bit "DPMI only", no "extensions". So OpenWatcom 32-bit or old Borland 16-bit DPMI stuff might complain. You might also want to disable swapping via CWSPARAM for your old hard drive since it tries to create a CWSDPMI.SWP file by default on C:\ drive. > Side Note: At boot, the system transfers the main OS files over to RAM disk, > reconfigures the environment > accordingly and primarily runs from RAM. Much better performance. A lot less > wear and tear on 25+ > year old drives. Besides, it has got to do something with all that RAM under > DOS. Oh, absolutely, it's way faster in RAM, even compared to USB jump drives. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, > On May 22, 2023, at 7:03 AM, Rugxulo wrote: > > Hi, > > On Mon, May 15, 2023 at 6:48 PM wrote: >> >> Let me show you a MEM print out from my Pentium Pro: >> >> NANSI3,536(3K) 0(0K) 3,536(3K) >> SHSURDRV 400(0K) 0(0K)400(0K) >> LBACACHE10,576 (10K) 0(0K) 10,576 (10K) >> CTMOUSE 3,104(3K) 0(0K) 3,104(3K) > > NNANSI [sic] can unload, so if you switch to that, all of these can > optionally be unloaded (if you put them last) to free up memory. Of > course, SHSURDRV will also unload your whole XMS RAM disk, too. Sure. But... Even with loading and keeping all that stuff, the system still has 94K free upper memory and 84K of that is consecutive. Unloading those drivers would not free up the 11K of Low memory used by the Kernel. It would just free upper memory of which there is plenty. The largest executable size is 628K. Nothing should every require over 600K of low memory to load. I would just like to see all ZEROs in the middle column. It also wouldn’t hurt to get another 10K added to the largest EXE that can be loaded. Actually, that MEM print out is outdated for that machine. Just to use up some more upper memory, it now loads CWSDMPI at boot. That brings free upper memory down to about 45K. But if upper memory gets too low or their are compatibility issues, I’ll stop loading it at boot. Side Note: At boot, the system transfers the main OS files over to RAM disk, reconfigures the environment accordingly and primarily runs from RAM. Much better performance. A lot less wear and tear on 25+ year old drives. Besides, it has got to do something with all that RAM under DOS. :-) Jerome ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 15, 2023 at 6:48 PM wrote: > > Let me show you a MEM print out from my Pentium Pro: > > NANSI3,536(3K) 0(0K) 3,536(3K) > SHSURDRV 400(0K) 0(0K)400(0K) > LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > CTMOUSE 3,104(3K) 0(0K) 3,104(3K) NNANSI [sic] can unload, so if you switch to that, all of these can optionally be unloaded (if you put them last) to free up memory. Of course, SHSURDRV will also unload your whole XMS RAM disk, too. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
> This could look something like this. The system boots as normal. A CONFIG > option like ‘DOSMOVE=UMB’ could exist. there exists already the DOS=UMB option, meaning "move as much as possible to UMB". IIRC when Bart implemented this he only moved DATA (buffers, LASTDRIVE=, current directories, ...) to UMB (the easy stuff), that's the 9K uppermemory that you see. while it may be possible to move more up, it's a lot of non trivial work with fairly low payoff. > The first device driver could check for that setting and would verify the > kernel could still be relocated. If it can, it would relocate or reload that > portion of the kernel to an UMB. the first drivers are NUL, COM1, LPT, FAT, etc. loaded way before JEMM > A memory manager is probably the best choice to perform the relocation. a memory manager provides the UMB to move to, but has no information at all what stuff mujst be relocated. > It is generally loaded before any other drivers. Since JEMM is the default > memory driver in FreeDOS, I suggest it would be the best choice to perform > the relocation when possible. currently after each DEVICE=XYZ executed the kernel searches for high memory and UMB. if found it relocates as much stuff to :0 and E000:0. however locating every far pointer to devices, the ListOfLists and a couple of other (linked) lists in the kernel would be a major - error prone - undertaking. forget just one location, and you have a broken kernel, because nobody will care to debug the kernel - again. > JEMM already pulls of quite a few tricks with memory. For example, my i686 > loads JEMM. Yet, it does not use any conventional or upper memory on that > machine. It doesn’t even show up with MEM. right. JEMM does impressive stuff :) > Although it would be a lot of work and probably never happen, it is not an > impossible task. that's a statement I could sign ;) Tom ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, > On May 16, 2023, at 8:43 PM, Bret Johnson wrote: > >>> But mostly, I think it would look really cool to have all Zeros in >>> the Conventional Memory Column. > >> I think this would be an exercise in futility. After all, there are >> parts of the kernel, which are the first part of (Free)DOS being >> loaded (by the boot code in the MBR) and then are being used to put >> in place any further drivers, etc, including any memory manager. I >> am not so sure that this part "could" be in fact moved up in higher >> memory (and thus no longer accessible in Real Mode) without opening >> up not just a can but a whole 55gal drum of worms... > > Ralf is correct. There are just some parts of DOS that must be below the > 640k barrier, particularly if you want to remain compatible with older > hardware (8088/80286 CPUs) and older programs. There are a lot of > complicated "games" that go on in the background to get some parts of some > programs above 640k or into Expanded or Extended Memory. If you want things > to work correctly, some things just need to be in conventional memory. Of course, there are actual system related items like the BDA that must remain where they are for many reasons. Of course on a system without memory or usable memory above 640K (like an original 8086), you are stuck using low memory as well. When MEM displays the contents of programs, I assume SYSTEM is part of the Kernel and does not include those items that cannot be located elsewhere. Even if it does include such things, those items do not add up to the reported SYSTEM usage of 11Kb. However, it does not need to be stuck in low memory on more capable hardware. On such machines, it should not break compatibility with very old programs that were designed for 8086 hardware. All pointers are OFFSET or SEGMENT:OFFSET. Wether the call to a DOS interrupt function points to segment in low memory (like 0100:1234) or upper memory (like CDEF:1234) will not matter. The inability to have calls to the kernel in an UMB block (above 640k, bellow 1M) for compatibility reasons is not accurate. If this was true, then no device drivers could be loaded high either. Programs that extend DOS functionality (like NANSI), would also break compatibility with old software as well. Any program that would not be compatible with kernel calls going to upper memory is most likely not compatible with FreeDOS in the first place. Such a program, would most likely be using undocumented tricks and require a specific version of MS-DOS. However, if support to relocate was included, it should be optional just like ‘DOS=HIGH’ to ensure compatibility. I’m not suggesting that having that portion of the kernel move to an UMB would be a simple undertaking. Nor, should it always be done. Only that, it would be nice to have the option for it to occur. To pull it off, several things would need done. As I see it, there are two general methods to relocate. Either method would require a lot of going over the kernel to make it possible and It would probably require at least some restructuring. It would need a mechanism to have it reinitialize it’s data for the new memory location. There would also need to be a method added to perform the actual move and reinitialize the data. It may be a lot simpler to just “shutdown” the kernel and reload it in an UMB. This could look something like this. The system boots as normal. A CONFIG option like ‘DOSMOVE=UMB’ could exist. The first device driver could check for that setting and would verify the kernel could still be relocated. If it can, it would relocate or reload that portion of the kernel to an UMB. A memory manager is probably the best choice to perform the relocation. It is generally loaded before any other drivers. Since JEMM is the default memory driver in FreeDOS, I suggest it would be the best choice to perform the relocation when possible. JEMM already pulls of quite a few tricks with memory. For example, my i686 loads JEMM. Yet, it does not use any conventional or upper memory on that machine. It doesn’t even show up with MEM. Although it would be a lot of work and probably never happen, it is not an impossible task. :-) Jerome > > > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
>> But mostly, I think it would look really cool to have all Zeros in >> the Conventional Memory Column. > I think this would be an exercise in futility. After all, there are > parts of the kernel, which are the first part of (Free)DOS being > loaded (by the boot code in the MBR) and then are being used to put > in place any further drivers, etc, including any memory manager. I > am not so sure that this part "could" be in fact moved up in higher > memory (and thus no longer accessible in Real Mode) without opening > up not just a can but a whole 55gal drum of worms... Ralf is correct. There are just some parts of DOS that must be below the 640k barrier, particularly if you want to remain compatible with older hardware (8088/80286 CPUs) and older programs. There are a lot of complicated "games" that go on in the background to get some parts of some programs above 640k or into Expanded or Extended Memory. If you want things to work correctly, some things just need to be in conventional memory. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
On 5/15/2023 4:46 PM, jer...@shidel.net wrote: As you can see, the only thing in low memory is part of SYSTEM using nearly 11K. The machine still has 94K free upper memory and 84K of that is still in a single large block. Yes, I know why this is "the way it is" and you don’t need to explain it to me. But, it doesn’t need to be that way. That portion “could" be moved and it would free nearly all lower memory. Possibly through some cooperation between the Kernel and Jemm. Obviously, the Interrupt Vectors, BDA, etc would need to remain. But, the rest could be in upper memory. But mostly, I think it would look really cool to have all Zeros in the Conventional Memory Column. I think this would be an exercise in futility. After all, there are parts of the kernel, which are the first part of (Free)DOS being loaded (by the boot code in the MBR) and then are being used to put in place any further drivers, etc, including any memory manager. I am not so sure that this part "could" be in fact moved up in higher memory (and thus no longer accessible in Real Mode) without opening up not just a can but a whole 55gal drum of worms... Ralf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
This is pretty good and matches pretty well with what MDGX/axcel216
has been able to achieve.
MS-DOS 6.22 (https://www.mdgx.com/mem6.htm#M6)
```
Modules using memory below 1 MB:
Name Total = Conventional + Upper Memory
MSDOS9,917 (10K) 9,917 (10K) 0(0K)
HIMEM1,168(1K) 1,168(1K) 0(0K)
EMM386 3,264(3K) 3,264(3K) 0(0K)
RECALL 2,544(2K) 0(0K) 2,544(2K)
DOSMAX 240(0K) 0(0K)240(0K)
XDVD22,272(3K) 0(0K) 2,272(3K)
IFSHLP 3,904(4K) 0(0K) 3,904(4K)
NANSI3,536(3K) 0(0K) 3,536(3K)
FILES4,448(4K) 0(0K) 4,448(4K)
FCBS96(0K) 0(0K) 96(0K)
WKBUFFER 528(1K) 0(0K)528(1K)
LASTDRIV 720(1K) 0(0K)720(1K)
INSTALL160(0K) 0(0K)160(0K)
CTMOUSE 3,584(3K) 0(0K) 3,584(3K)
COMMAND 3,696(4K) 0(0K) 3,696(4K)
ZENO174 1,120(1K) 0(0K) 1,120(1K)
MSCDEX 16,080 (16K) 0(0K) 16,080 (16K)
SMARTDRV35,264 (33K) 0(0K) 35,264 (33K)
HYPERKEY 2,880(3K) 0(0K) 2,880(3K)
Free 675,504 (660K)640,314 (625K) 35,200 (34K)
Memory Summary:
Type of Memory Total =Used+Free
-- -- --
Conventional 655,360 15,056 640,314
Upper125,792 90,592 35,200
Reserved 393,216 393,2160
Extended (XMS)* 65,934,4965,280,928 60,653,568
-- -- --
Total memory 67,108,8645,779,792 61,329,072
Total under 1 MB 781,152 105,648 675,504
Total Expanded (EMS)33,947,648 (33,152K)
Free Expanded (EMS)*33,505,280 (32,720K)
* EMM386 is using XMS memory to simulate EMS memory as needed.
Free EMS memory may change as free XMS memory changes.
Largest executable program size640,288 (625K)
Largest free upper memory block 31,776(31K)
Available space in High Memory Area 15,920(16K)
MS-DOS is resident in the high memory area.
```
MS-DOS 7.1 (https://www.mdgx.com/mem7.htm#M)
```
Modules using memory below 1 MB:
Name TotalConventional Upper Memory
--- -
SYSTEM 16,064 (16K) 9,712 (10K) 6,352(6K)
HIMEM1,120(1K) 0(0K) 1,120(1K)
NANSI3,536(3K) 0(0K) 3,536(3K)
IFSHLP 2,864(3K) 0(0K) 2,864(3K)
XDVD22,272(3K) 0(0K) 2,272(3K)
COMMAND 9,664(9K) 0(0K) 9,664(9K)
RECALL 2,544(2K) 0(0K) 2,544(2K)
MSCDEX 48,704 (48K) 0(0K) 48,704 (48K)
SMARTDRV35,072 (34K) 0(0K) 35,072 (34K)
ZENO174 1,120(1K) 0(0K) 1,120(1K)
CTMOUSE 3,584(3K) 0(0K) 3,584(3K)
XMSDSK 688(1K) 0(0K)688(1K)
NOOFF 336(0K) 0(0K)336(0K)
Free 682,976 (667K) 644,048 (629K) 39,184 (38K)
Memory Summary:
Type of Memory Total Used Free
--- --- ---
Conventional 654,33610,304 644,048
Upper 163,888 124,70439,184
Reserved0 0 0
Extended (XMS)267,255,76030,310,352 219,086,848
--- --- ---
Total memory 268,040,19230,445,840 219,756,240
Total under 1 MB 818,224 135,248 682,976
Largest executable program size 644,022 (629K)
Largest free upper memory block 30,944 (30K)
Available space in High Memory Area 2,624(3K)
MS-DOS is resident in the high memory area.
```
On Mon, May 15, 2023 at 4:48 PM wrote:
>
> Hi All,
>
> Let me show you a MEM print out from my Pentium Pro:
>
> Modules using memory below 1 MB:
>
> Name Total Conventional Upper Memory
>
> SYSTEM 19,888 (19K) 10,944 (11K) 8,944(9K)
> LOGGER 1,760(2K) 0(0K) 1,760(2K)
> NANSI3,536(3K) 0(0K) 3,536(3K)
> COMMAND 4,400(4K) 0(0K)
