Re: [Freedos-devel] weird memory map explained (was numerous problems...)
Hello Eric, On at 2021-05-27 12:38 +0200, Eric Auer wrote: Sorry but given that my best guess is that you have misunderstood the problem, you are not yet an experienced JEMMEX programmer. Again, I ask you to use the "do not load EMM386" workaround for now. If the topic is REALLY exciting for you, you can start by learning how to use the protected mode features 386SWAT, IDEBUG or other advanced debugging tools which let you trace across real and protected modes: real mode, vm86 mode, protected mode to understand what your BIOS is doing, or even how the internal workings of EMM386 are. But I warn you, those are quite complex. I'm not aware of any debugger called "IDEBUG". However, presumably you meant to refer to "lDebug" (first letter is noncapital L). And regarding lDebug, you would not be able to inspect "the internal workings of EMM386" with it. Let me quote my announcement of 2021-05-05: > It runs in Real or Virtual 86 Mode, as a DOS application, > DOS TSR, or bootloaded instead of an OS kernel. The DPMI- > capable lDebugX also can run as a DPMI client. EMM386 does not run as a DPMI client, so lDebug cannot debug it. 386SWAT may be able to debug an EMM, it seems to be more advanced in the modes in which it can operate. Does it reserve a block at linear address 58000? If you use my manual MCB edit trick, will more DOS apps work without a crash? Which apps will keep crashing nevertheless? Those are exciting questions which do not require the extreme skill level of debugging protected mode usage conflicts which you can easily avoid anyway by NOT loading EMM386 and JEMMEX. Note that this is mostly of academic interest: NORMAL people would just assume that if 5800:0 is reserved, the BIOS does not cooperate sufficiently with DOS. They would install Linux or Windows as next step and run DOS inside dosemu2 or dosbox. I created a little script to allocate an MCB at an arbitrary address. I uploaded it to [1]. Usage: Install lDebug (release 2) from the FreeDOS package or the zipball or tarball [2]. Start LDEBUG.COM or LDEBUGU.COM in the directory you have the reserve.sld script file, then enter the following: r v4 := 5800 r v5 := 100 y reserve.sld This should reserve an S MCB at "0x00058000-0x00058fff" if possible. You can also run the lDebug command "dm" before and after using reserve.sld to verify that it allocated the correct block. Regards, ecm [1]: https://pushbx.org/ecm/test/reserve.sld [2]: https://pushbx.org/ecm/download/ldebug/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] weird memory map explained (was numerous problems...)
Hi Paul, > I was looking in BIOS interrupts info from: > http://www2.ift.ulaval.ca/~marchand/ift17583/dosints.pdf > INT 15 - AH = 89h SYSTEM - SWITCH TO VIRTUAL MODE (AT,XT286,PS50+) You can do that, but your problem is in the opposite direction: JEMMEX, JEMM386, EMM386 etc. have already switched to protected mode because this is necessary to provide UMB and EMS on modern hardware. Ancient hardware may additionally support hardware EMS. UMBPCI can be used to allocate UMB in areas above 640 kB which happen to be available on modern hardware according to the map. So you already are in protected mode when your BIOS blindly assumes you are not and activates protected mode again, which of course does not work. So EMM386 receives an exception and shows you an error message about the BIOS. > And that answered a bit of question to me, how can DOS > programs and BIOS cooperate with a common GDT table? See above, it does not solve the problem. Even if the BIOS would use that int 15 call to switch to protected mode, EMM386 would not be able to combine "BIOS wants to enter protected mode with specified GDT and IRQ mapping" with "EMM386 alreay needs those things to have different values", so it would not help if EMM386 itself provides an alternative version of int 15 so the BIOS can call that. The other way round does not help either: EMM386 could use this call to switch to protected mode, but the result would be the same as what you already have: The system is in protected mode and has to stay here while EMM386 is active. So when you now ask your BIOS to do something which makes your (unusual!) BIOS "switch from real mode to protected mode" without looking at where it came from, it would try to switch from protected mode to protected mode and fail, as it already does now. The only difference could be that if you use the BIOS call to switch to protected mode, the BIOS could take a "mental note" and remember that you already ARE in protected mode. And stop attempts to switch to protected mode later. I am pessimistic about that. Unless you have very good reasons to load EMM386, please focus on other problems first and simply skip loading EMM386 on your system. That way, the system will stay in real mode and will have no problems when your BIOS switches it to protected mode temporarily :-) HIMEM and XMGR style drivers will not keep the system in protected mode non-stop: They only use protected mode during the moments when you access XMS contents. AND they even are polite enough to let the BIOS do the access when they detect that protected mode already is in use, as far as I remember :-) > Maybe I could try to hack something about it... not sure I am good enough to > do it. Sorry but given that my best guess is that you have misunderstood the problem, you are not yet an experienced JEMMEX programmer. Again, I ask you to use the "do not load EMM386" workaround for now. If the topic is REALLY exciting for you, you can start by learning how to use the protected mode features 386SWAT, IDEBUG or other advanced debugging tools which let you trace across real and protected modes: real mode, vm86 mode, protected mode to understand what your BIOS is doing, or even how the internal workings of EMM386 are. But I warn you, those are quite complex. So please focus on the other questions instead: What is your e820 memory map if you boot into plain DOS without EMM386? Does it reserve a block at linear address 58000? If you use my manual MCB edit trick, will more DOS apps work without a crash? Which apps will keep crashing nevertheless? Those are exciting questions which do not require the extreme skill level of debugging protected mode usage conflicts which you can easily avoid anyway by NOT loading EMM386 and JEMMEX. Note that this is mostly of academic interest: NORMAL people would just assume that if 5800:0 is reserved, the BIOS does not cooperate sufficiently with DOS. They would install Linux or Windows as next step and run DOS inside dosemu2 or dosbox. But given my interest in "DOS on too modern hardware" and your interest in challenges, I suggest that you keep doing some experiments. NOT protected mode ones, though: Those should wait for a later moment in learning low-level programming. So I ask you to not spend too much time with 386SWAT and the combined extreme complexities of "BIOS versus JEMMEX", but I cannot resist mentioning http://www.sudleyplace.com/swat/ already. Do NOT use that ;-) Instead, read the e820 memory map in DOS (if you find no tool for it, do it by hand using DEBUG) and try that "reserve 5800:0 block" MCB trick if it turns out the 5800:0 really is reserved in plain DOS without loading (J) EMM386 or JEMMEX. Big chance that it is reserved. Thanks! Regards, Eric ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] weird memory map explained (was numerous problems...)
I was looking in BIOS interrupts info from: http://www2.ift.ulaval.ca/~marchand/ift17583/dosints.pdf When I saw: INT 15 - AH = 89h SYSTEM - SWITCH TO VIRTUAL MODE (AT,XT286,PS50+) BL = interrupt number of IRQ0 (IRQ1-7 use next 7 interrupts) BH = interrupt number of IRQ8 (IRQ9-F use next 7 interrupts) DS:SI -> GDT for protected mode offset 0h null descriptor 8h GDT descriptor 10h IDT descriptor 18h DS 20h ES 28h SS 30h CS 38h uninitialized, used to build descriptor for BIOS CS CX = offset into protected-mode CS to jump to Return: CF set on error AH = 0FFh error enabling address line 20 And that answered a bit of question to me, how can DOS programs and BIOS cooperate with a common GDT table? I am not sure at all I have the "right" Jemm(Ex) source code here, but looking at: https://github.com/Baron-von-Riedesel/Jemm/blob/master/src/JEMM16.ASM line 988 and more, it seems Jemm does not use that instruction to enter protected mode, but change CR0 bit 1 itself. Maybe I could try to hack something about it... not sure I am good enough to do it.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] weird memory map explained (was numerous problems...)
Tom said: > [ 0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved >if this is real (that's a BIG if), then this machine is not DOS >compatible. Well... Tom was right about the BIG if. First here what I now believe is the real memory map of my computer: [ 0.00] e820: BIOS-provided physical RAM map: [ 0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable [ 0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved [ 0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [ 0.00] BIOS-e820: [mem 0x0010-0xb3cb6fff] usable [ 0.00] BIOS-e820: [mem 0xb3cb7000-0xb3cedfff] ACPI data [ 0.00] BIOS-e820: [mem 0xb3cee000-0xb4096fff] usable [ 0.00] BIOS-e820: [mem 0xb4097000-0xb4097fff] ACPI NVS [ 0.00] BIOS-e820: [mem 0xb4098000-0xb4098fff] reserved [ 0.00] BIOS-e820: [mem 0xb4099000-0xc0c1bfff] usable [ 0.00] BIOS-e820: [mem 0xc0c1c000-0xc2473fff] reserved [ 0.00] BIOS-e820: [mem 0xc2474000-0xc248afff] ACPI data [ 0.00] BIOS-e820: [mem 0xc248b000-0xc2585fff] usable [ 0.00] BIOS-e820: [mem 0xc2586000-0xc28adfff] ACPI NVS [ 0.00] BIOS-e820: [mem 0xc28ae000-0xc2fa1fff] reserved [ 0.00] BIOS-e820: [mem 0xc2fa2000-0xc2ff] usable [ 0.00] BIOS-e820: [mem 0xc300-0xc7ff] reserved [ 0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [ 0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [ 0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [ 0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [ 0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [ 0.00] BIOS-e820: [mem 0xff00-0x] reserved [ 0.00] BIOS-e820: [mem 0x0001-0x000236ff] usable [ 0.00] NX (Execute Disable) protection: active [ 0.00] SMBIOS 3.1 present. [ 0.00] DMI: System manufacturer System Product Name/PRIME H310M-C R2.0, BIOS 1004 09/06/2019 And now, for the explanation, I was booting Linux in UEFI map. So I believe what it was doing was converting internally the UEFI memory map (there is a service for getting that) in BIOS-e820 table. And the table can be a little bit different than the one given when booted in real mode, as we can see. I am sorry for all the fuss.___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
