> 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 FFFF: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
