flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > DOS > unREAL mode

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
Ninho



Joined: 07 May 2010
Posts: 16

Tomasz Grysztar wrote:

bitRAKE wrote:

http://wikipedia.org/wiki/Unreal_mode wrote:
"Huge" real mode is attained by, in addition, loading the code selector (CS) from a descriptor allowing access to the whole memory and having the 32-bit attribute ("D" bit) set to one.


Who invents this nomenclature? It doesn't make any sense to me. Also, it is earlier mentioned just as a synonym to FRM (and it makes much more sense). Do you know any place where the "huge real mode" was used in the meaning of 32-bit unreal? Well, the article does not cite any sources - perhaps these days it works like "whoever gets to edit the wikipedia first, gets to invent the names".




Oh, Tomasz ! I just stumbled upon this old part of a discussion; I am the one to be blamed or praised for redacting large parts of the Wikipedia article and in particular introducing "huge real mode", but I did not invent the term, that would be contrary to WP policies - HRM was used in Ralf Brown's famous interrupt list along with his description of Helix RM386 API. That is some "source". I don't know if Ralf coined the expression by himself or Helix named it so - I suspect rather the latter. I remain guilty of not quoting my source in that article, (it's been a long time... should go back there and add a reference).

Several people I'm sure have independently come upon RM32/HRM over the years. Commercially it's been promoted by Helix and bundled without fanfare in TSR programs such as Logitech mouse drivers.

Regards !

--
Ninho
Post 24 Jan 2011, 15:47
View user's profile Send private message Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 208
Location: film "CandyMan" directed through Bernard Rose
In 16-bit unreal mode this instruction is valid.

Code:

mov [cs:1234h],ax




In 32-bit unreal mode this instruction is valid.

Code:

mov [cs:12345678h],eax




Writting with cs override is invalid in protected mode, so it is indeed real mode.

_________________
smaller is better
Post 26 Oct 2014, 18:18
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 501
Location: New Zealand

CandyMan wrote:
In 32-bit unreal mode this instruction is valid.

Code:

mov [cs:12345678h],eax



and it is also valid in 16-bit unreal mode. Wink

Edit: oops, I should've put my glasses on before shooting my mouth off Very Happy
Well, it would be valid in 16-bit unreal mode if it was an es: override, but not for the cs: override.

_________________
FAMOS - the first memory operating system
Post 27 Oct 2014, 04:40
View user's profile Send private message Visit poster's website Reply with quote
freecrac



Joined: 19 Oct 2011
Posts: 117
Location: Germany Hamburg

neville wrote:

CandyMan wrote:
In 32-bit unreal mode this instruction is valid.

Code:

mov [cs:12345678h],eax



and it is also valid in 16-bit unreal mode. Wink

Edit: oops, I should've put my glasses on before shooting my mouth off Very Happy
Well, it would be valid in 16-bit unreal mode if it was an es: override, but not for the cs: override.


In 16-bit unreal mode i like to use instructions without a segment override prefix using the default segment register of DS.

Code:
xor ebxebx
mov bxds
shl ebx4
mov edi12345678h
sub ediebx
mov [edi],eax

Post 27 Oct 2014, 14:24
View user's profile Send private message Send e-mail Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 208
Location: film "CandyMan" directed through Bernard Rose
I only wrote that in the protected mode writing with cs prefix is generating the exception.
In the real mode and unreal mode this instruction is correct. It is distinguishing the real mode than protected.
In unreal 32-bit mode this instruction is valid, but is invalid in unreal 16-bit mode.

Code:

mov [cs:12345678h],eax 



He is happening this way because 64kb limit was crossed.
I am recommend to use the debugger from http://board.flatassembler.net/topic.php?p=104631#104631

_________________
smaller is better
Post 27 Oct 2014, 16:08
View user's profile Send private message Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 208
Location: film "CandyMan" directed through Bernard Rose
whether is possible to use the big stack (>64 KB) in the 32-bit flat real mode?
Results from my tests that yes. The big stack is needed for me e.g. for the recursive sorting of many elements.
Soon I am going to make the program available to tests which is using the big stack under flat mode. I don't know whether the big stack is possible on all processors Intel (works on my AMD).

_________________
smaller is better
Post 25 Nov 2015, 18:39
View user's profile Send private message Reply with quote
CandyMan



Joined: 04 Sep 2009
Posts: 208
Location: film "CandyMan" directed through Bernard Rose
here big stack test program, start and write whether is working


Description:
Download
Filename: BIGSTACK.RAR
Filesize: 1.91 KB
Downloaded: 34 Time(s)


_________________
smaller is better
Post 26 Nov 2015, 16:14
View user's profile Send private message Reply with quote
Shahada



Joined: 25 Jul 2008
Posts: 75
Is working.

-------------------------------------------------------------------------------------

None saw it;
Neither did Aminadab appear.

Ya Allah Ya Allah Ya Allah
Post 27 Nov 2015, 15:11
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.