OSDev.org

Dear All;
How do I R/W memory above 16M before switching to protected mode? TIA.

You don't?

Boba wrote:How do I R/W memory above 16M before switching to protected mode? TIA.

In general, you can't.

A workaround is Unreal_Mode, which you switched into protected mode first, apply changes to selectors and switch back to real mode.
You can then access the 32-bit address space with a32 prefix and 32-bit registers, until the segment register get reset.

See the wiki for detail and its limitations.

thank you guys. so you're saying bioses (during post) run the memory test in 32-bit mode.
right?

Why do you care how bios do it? How BIOS actually do it is implementation specific.
btw memory tests may be assisted with special hardware function, it's not likely to be a bunch of 32-bit MOVs or TESTs.

all it tells me it's doable. i thought i could do it as well with no 16/32 switching.
'unreal mode' is something new to me. i'm currently playing with it...

If you're in 16-bit mode you might as well use the BIOS interrupts to get memory. Or if you're going to probe, wait until you are in protected mode. No need to make it harder on yourself then it already is.

Given that all non-16-bit x86 implementations that I'm aware of implement descriptor caches, I use unreal mode in my boot loader on systems with BIOS-type firmware. It's not more difficult---on the contrary, you get a 4 GiB address space and are able to use the BIOS interrupt handlers. That means no more switching back and forth.

bubach wrote:If you're in 16-bit mode you might as well use the BIOS interrupts to get memory...

that's what i wish i could do, but my knowledge is limited by 16M (int15.87 to be exact).
when you say 'interrupts' - what do you mean?

There are many ways to detect memory; your primary tool being INT 15h, EAX = E820h (BIOS) or GetMemoryMap() (EFI/UEFI), as defined by ACPI. For very old systems where this method is not supported, you may wish to fall back to on one or more of the other methods. Clicky for the wiki!

Hi,

Love4Boobies wrote:... implement descriptor caches, I use unreal mode in my boot loader on systems with BIOS-type firmware. It's not more difficult---on the contrary, you get a 4 GiB address space and are able to use the BIOS interrupt handlers. That means no more switching back and forth.

If the BIOS interrupt handlers, say, reload the segment registers (and you can't be sure that they don't), then wouldn't you need to switch back to unreal mode? I find that to be as bad as constantly switching between real and protected mode.

Regards,
Shikhin!

Love4Boobies wrote:Given that all non-16-bit x86 implementations ... implement descriptor caches, I use unreal mode ...

not sure i'm in line with you: are you using 'unreal mode' in your 'non-16-bit' code?
i need to access the upper memory before the pm kicks in. to me, 'non-16-bit' means 32-bit
protected mode. although my target range is very narrow, i'd like to avoid the 'implementation
specific' approach as mentioned by bluemoon.
related to this, i wonder if dos hi-memory drivers (and 32-bit extenders) use pm?

Shikhin wrote:Hi,

Love4Boobies wrote:... implement descriptor caches, I use unreal mode in my boot loader on systems with BIOS-type firmware. It's not more difficult---on the contrary, you get a 4 GiB address space and are able to use the BIOS interrupt handlers. That means no more switching back and forth.

If the BIOS interrupt handlers, say, reload the segment registers (and you can't be sure that they don't), then wouldn't you need to switch back to unreal mode? I find that to be as bad as constantly switching between real and protected mode.

I dobut there are many implementations that do that, as much boot loader code relies on this technique; other than that, there would be little reason for the BIOS to do anything of that nature. If you want to play it somewhat safer, only use FS or GS. Either way, if this problem even exists in the real world, it's very uncommon.

Boba wrote:

Love4Boobies wrote:Given that all non-16-bit x86 implementations ... implement descriptor caches, I use unreal mode ...

not sure i'm in line with you: are you using 'unreal mode' in your 'non-16-bit' code?
i need to access the upper memory before the pm kicks in. to me, 'non-16-bit' means 32-bit
protected mode. although my target range is very narrow, i'd like to avoid the 'implementation
specific' approach as mentioned by bluemoon.
related to this, i wonder if dos hi-memory drivers (and 32-bit extenders) use pm?

You misunderstand; a non-16-bit x86 implementation is any 32/64-bit x86 CPU (i.e., 80386 or later).

Love4Boobies wrote:There are many ways to detect memory; your primary tool being INT 15h, EAX = E820h (BIOS)...

... and after detecting it, how do i access it beyond 16M before going 32-bit?

Boba wrote:

Love4Boobies wrote:There are many ways to detect memory; your primary tool being INT 15h, EAX = E820h (BIOS)...

... and after detecting it, how do i access it beyond 16M before going 32-bit?

You've already been answered: by switching to unreal mode.