flat assembler
Message board for the users of flat assembler.

Index > DOS > Question about real mode addressing

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
DOS386,

If you have loaded (in PM) flat descriptors for DS, ES, FS and GS, then (in RM) load selector to (e.g.) DS, flat descriptors for ES, FS and GS are still in effect.
Post 18 Jan 2009, 11:36
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> to (e.g.) DS, flat descriptors for ES, FS and GS are still in effect.

Right ... loading one segment register in RM destroys the higher limit in the one only ... and it can't be recovered anymore in RM.
Post 18 Jan 2009, 13:31
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
DOS386,

That's exactly what I've meant by "more and more real". Wink
Post 18 Jan 2009, 17:33
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
baldr wrote:
DOS386,

That's exactly what I've meant by "more and more real". Wink

Do you actually have experience of this? Because in my experience it is not the case. For example in FAMOS I setup "Flat Real Mode" once only at boot time, set 32-bit limits etc and then never touch them again.

FAMOS normally runs with (RM) DS=0000, but DS gets changed extensively by "Limited Legacy Programs" (de-DOS'd old DOS games etc in FAMOS). Then after the LLP has run, all FAMOS does is the simple 16-bit xor ax,ax / mov ds,ax and the 32-bit limits are still there. My debugging also shows that the 32-bit limits are also still in effect while the LLP's are running.

_________________
FAMOS - the first memory operating system
Post 18 Jan 2009, 18:28
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
In real mode address calculation works similar to this:

<segment register>*16+<16bitAddress>+<hiddenSelectorOffset>

And each time the segment register is updated in RM the hidden selector part is not changed.

At CPU reset the hidden selector part is initialised with a 64K limit and an offset of 0. When using Unreal mode it is common to change the limit to 4G and leave the offset at 0. I know of no way in RM mode to change the hidden selector portion of each segment register.
Post 19 Jan 2009, 10:45
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
That makes perfect sense revolution, and fits with my experience, but remains at variance with baldr's assertions above.

_________________
FAMOS - the first memory operating system
Post 19 Jan 2009, 19:14
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
One thing I forgot to mention is that in RM mode the address can also be 32bit when using Unreal mode or with an operand override prefix in RM. So it becomes this:

<segment register>*16+<16/32bitAddress>+<hiddenSelectorOffset>

And also the limit check is done in the background to cause an exception if the calculation is above the hidden selector limit. Note that the limit check is done before adding the selector offset. With a 4G limit then no exception can be generated because the limit cannot be exceeded.
Post 19 Jan 2009, 19:28
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
neville & revolution,

My experience with unreal mode is pretty outdated (10+ years ago), probably what I've said was right in some variant of 486 architecture (Am5x86/Cx5x86? They were pretty popular those days).

Sorry for misinformation, I should have checked it better.
Post 19 Jan 2009, 23:12
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
ok baldr, no problem, but I hope you're also wrong about those Cyrix chips and other "486 variants" because if you're right, FAMOS could easily crash on them Wink

_________________
FAMOS - the first memory operating system
Post 20 Jan 2009, 19:24
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Some time ago a user of the DOS version of FASM reported that it wasn't working on his Cyrix without DPMI but as far as I can recall Tomasz managed to change the code in order to make it compatible with Cyrix.

[edit] Here is the link: http://board.flatassembler.net/topic.php?t=3946 . BTW, seems that there was no fix other than using DPMI Razz
Post 20 Jan 2009, 19:39
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
LocoDelAssembly,

Probably his DPMI didn't reload descriptor on fault.
Post 20 Jan 2009, 23:15
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
No, the problem was that fasm wasn't running in DPMI mode when the processor was in real mode so it was always switching to unreal mode which as the thread suggest is unsupported by 486SLC and some emulators like Bochs.

The freeze was when DPMI wasn't used, not when it was.
Post 21 Jan 2009, 00:09
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Is it that the CPUs that don't/won't support the unreal mode have a hard coded limit of 64K when in RM. That is, do they ignore the hidden selector limit setting updated by PM? Or, is it that the code selector setting for 32bit code is ignored? Or, is it both?

It would be interesting to compile a list of the CPUs that have this "feature".
Post 21 Jan 2009, 02:05
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

Or, is it that the code selector setting for 32bit code is ignored?

This one.

Tomasz Grysztar wrote:
It fails when the code bitness bit is ignored in real mode. On Intel and AMD processors when you switch back to real mode with the descriptor in CS having the code type set to 32-bit, it still executes the 32-bit code. When processor (like this Cyrix) ignores these settings of code descriptor in real mode, it won't work.
For unreal mode to work correctly I need also to move the base of real mode IDT, so I can switch between 32-bit and 16-bit modes to execute the interrupt handler from the original IDT (at base 0).

( http://board.flatassembler.net/topic.php?p=28993#28993 )

BTW, you can salute yourself one post below the one I quoted Wink
Post 21 Jan 2009, 02:23
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
Oh shit, a 3.5 year old post. I completely forgot. Thanks for the reminder.
Post 21 Jan 2009, 02:25
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
revolution wrote:
Is it that the CPUs that don't/won't support the unreal mode have a hard coded limit of 64K when in RM. That is, do they ignore the hidden selector limit setting updated by PM? Or, is it that the code selector setting for 32bit code is ignored? Or, is it both?

It would be interesting to compile a list of the CPUs that have this "feature".
All 64-bit CPU's because there is no "long mode" equivalent of unreal mode... This is tragic. I hope one day this will change ...

_________________
FAMOS - the first memory operating system
Post 21 Jan 2009, 19:35
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
neville wrote:
All 64-bit CPU's because there is no "long mode" equivalent of unreal mode... This is tragic. I hope one day this will change ...
I strongly doubt it will change. So just deal with it. Map the paging 1-1 at startup and then forget about the paging. Solved.
Post 22 Jan 2009, 00:27
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
revolution wrote:
neville wrote:
All 64-bit CPU's because there is no "long mode" equivalent of unreal mode... This is tragic. I hope one day this will change ...
I strongly doubt it will change. So just deal with it. Map the paging 1-1 at startup and then forget about the paging. Solved.
That sounds incredibly simple, and I suppose it is - when you know how. Trouble is, I find protected mode programming incredibly confusing. If I could set up a 64-bit data environment with 1-1 page mapping for all installed memory which is equivalent to a 32-bit unreal data environment, believe me I would do it... My hunch is that the 64-bit unreal CPU will be developed before I figure it out Wink

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 02:31
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
What advantage is to be gained by 64bit unreal mode? Sure, you don't have the paging mechanism involved, but I see that as a detriment rather than an advantage.

The fragmented memory space can become tricky to deal with. You will have LFB's and I/O buffers messing up the ability to have contiguous chunks of RAM at your disposal. With just a small amount of programming to set up the page tables I think it is worth it to get into a memory environment where things are laid out more logically. Yes, this is no longer 1-1, it is a much nicer improvement over the simple 1-1 scheme.
Post 23 Jan 2009, 02:51
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Unreal mode or Flat Real mode has several advantages for me. It provides a convenient no-hassle easily set-up environment for processing bulk data held in a linear 32-bit address space, up to 4 gigabytes. For example, it gives me direct access to all BIOS interrupts which saves a lot of time if you don't have to first write, then test and then debug your own I/O routines, for example. (16-bit code is not a problem - it works with 32-bit addresses just fine)

I guess I see protected mode as being "over-protective". We all use computers to do different things, and if somebody wants to run their 64-bit CPU in the highest possible "privilege" with all physical memory directly addressable by a 64-bit register, why shouldn't they be able to? But X86-64 has made this impossible. Why did they do that?

Now back to reality, I don't understand why 1-1 mapping has to mess up memory (if thats what you're saying). Couldn't all buffers and page tables etc be located in, say, a dedicated low memory area, so that all memory above the buffers etc is a single contiguous chunk?

Quote:
With just a small amount of programming to set up the page tables I think it is worth it to get into a memory environment where things are laid out more logically
. This sounds kind of ironic because what could be a more logical layout than a single flat linear memory space - aka unreal mode?

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 03:54
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.