Bonjour Paul,
> But I am mostly here for testing FreeDOS and help others not > to encounters the problem I encounter. I do not understand that sentence. > In my opinion, instructions for turning off and on protected mode, > and storing, restoring registers value are pretty cheap in time. Possibly, but disabling protected mode to call the BIOS would make all UMB and EMS vanish during that period which instantly breaks everything which uses BIOS while also using UMB or EMS in a way where the BIOS has to access the UMB or EMS contents. > My suggestion, is make it work "slow" but working for everyone, and > allow an option to be "fast" and insecure. That is exactly why one of my most common suggestions to avoid instabilities is "Have you tried it again without EMM386?" ;-) It is not uncommon that the BIOS fails to properly express the ins and outs of the memory map or fails to cooperate with DMA in protected mode. Your case where the BIOS fails to cooperate with protected mode in general is unusual, but avoiding EMM386 automatically avoids UMB or EMS page frame (if EMS 3.2, if you use "NOEMS" for EMS 4.0, no problem) area conflicts. The next step for people with "classic" EMM386 problems would be to let them manually specify memory exclusion areas to make some of their UMB work again, to re-gain both stability and at least some UMB. But on your system, I recommend to try without EMM386 in general and not just limit memory areas for EMM386 / JEMMEX. > >...and of course you >> may still have to apply hat MCB chain editing trick >> to protect this special 5800:0 area your BIOS uses. > I think we don't see things the same way on that point. > I believe my BIOS is not very special (AMIBIOS), just relatively recent. > So I believe others are likely to encounter reserved memory in the > memory area DOS normally use. You are the first person who has reported a reserved area below 640 kB that I remember at all, so it does feel quite unusual. Of course the BIOS brand is not special, but taking care of needs of DOS and DOS apps has gone down a lot relatively recently only. > I believe the real solution is not to ask users to edit FreeDOS MCB chain, > but modify FreeDOS to allow memory not to be consecutive and automatically > not use memory reserved by the BIOS. That would of course be perfect, but as you have the only "patient" yet, I would still suggest that you first do the experiment by hand to see whether it makes some apps work which have crashed before. Also note that if more BIOSes start reserving memory below 640 kB, it will impact quite a few DOS apps which want several 100 kB of consecutive free DOS memory. Anyway, an automatic workaround tool would work by reading the BIOS memory map and installing reserved MCB areas around all BIOS reported reserved memory below 640 kB. It could be implemented as app or, for earlier loading, as driver. I do not think that HIMEMSX will be REALLY useful for you: Only Japheth's modified version of RDISK can use > 4 GB of memory yet, while old apps would only gain access to a full 4 GB of RAM as opposed to the 3 GB which you have free before the 4 GB boundary. You would probably have to look into te source code to see whether HIMEMSX uses PAE or whether it uses actual 64-bit long mode. The latter can probably cause more overhead for each call to XMS copy functions and it would certainly have been more work to develop. Regards, Eric PS: I am busy checking Bret's GPT code for making a version which kernel developers can read (it is NASM) to write a C version of the algorithm and add that to the FreeDOS kernel. Interestingly, his USB driver can use either DPMS or EMS and either real or protected mode. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
