hi-memory access in real-mode

Programming, for all ages and all languages.
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

hi-memory access in real-mode

Post by Boba »

Dear All;
How do I R/W memory above 16M before switching to protected mode? TIA.
User avatar
Solar
Member
Member
Posts: 7615
Joined: Thu Nov 16, 2006 12:01 pm
Location: Germany
Contact:

Re: hi-memory access in real-mode

Post by Solar »

You don't?
Every good solution is obvious once you've found it.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: hi-memory access in real-mode

Post by bluemoon »

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.
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

Re: hi-memory access in real-mode

Post by Boba »

thank you guys. so you're saying bioses (during post) run the memory test in 32-bit mode.
right?
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: hi-memory access in real-mode

Post by bluemoon »

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.
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

Re: hi-memory access in real-mode

Post by Boba »

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...
User avatar
bubach
Member
Member
Posts: 1223
Joined: Sat Oct 23, 2004 11:00 pm
Location: Sweden
Contact:

Re: hi-memory access in real-mode

Post by bubach »

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.
"Simplicity is the ultimate sophistication."
http://bos.asmhackers.net/ - GitHub
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: hi-memory access in real-mode

Post by Love4Boobies »

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.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

Re: hi-memory access in real-mode

Post by Boba »

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?
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: hi-memory access in real-mode

Post by Love4Boobies »

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!
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
shikhin
Member
Member
Posts: 274
Joined: Sat Oct 09, 2010 3:35 am
Libera.chat IRC: shikhin
Contact:

Re: hi-memory access in real-mode

Post by shikhin »

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!
http://shikhin.in/

Current status: Gandr.
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

Re: hi-memory access in real-mode

Post by Boba »

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?
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: hi-memory access in real-mode

Post by Love4Boobies »

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).
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Boba
Posts: 14
Joined: Wed Dec 28, 2011 9:53 am

Re: hi-memory access in real-mode

Post by Boba »

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?
User avatar
Love4Boobies
Member
Member
Posts: 2111
Joined: Fri Mar 07, 2008 5:36 pm
Location: Bucharest, Romania

Re: hi-memory access in real-mode

Post by Love4Boobies »

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.
"Computers in the future may weigh no more than 1.5 tons.", Popular Mechanics (1949)
[ Project UDI ]
Post Reply