Hi, > On May 16, 2023, at 8:43 PM, Bret Johnson <bretj...@juno.com> 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
