Is it possible to address more than 1MB in real-mode

Wolfgang Kern wrote:
>  Dirk Wolfgang Glomp wrote:
>
> 
>
> 
>
>
> I cannot image that IRQs can work while in Unreal mode.

Don't have to imagine it. Run the code!
 
>
> 
> do that?
>
>
> One problem is that the CPU actually switches between RM/PM when CS is
> reloaded,

???

> the trick to set data-segment registers to flat/unlimted,
> right after b0(CR0) is set, works only until CS become altered.

Nonsense! What effect would reloading CS (still/again in RM) have on
limits for ds, es, fs, gs???

> So the final IRET in any IRQ-handler (timer,key,mouse...) will do this
> unwanted mode transition (turning BigReal/UnReal into PM).

Into PM??? How???

> Another thing to assume is that RM IRQ-handlers may temporary reload
> DS/ES/.. and so reset the limit to 64KB again.

Reloading segregs in RM does *not* reset limits!!! If an IRQ handler
switches to PM, it will probably set limits to 0FFFFh (like we're
"supposed" to) when it switches back to RM. In this case (never seen
it), an SOE will occur - and our handler will put us back in "relimited
real mode".

> There are some workarounds for this problems, like what Frank posted,

Herman Dullink. I ain't that smart.

> but an easier way is to disable IRQs for short periods or use only
> FS and GS for flat-addressing, these two are rare used in plain DOS.

No need to disable IRQs once we're back in RM. Sticking with FS and GS
might make sense - we may want DS and/or ES loaded with the "real",
"unflat" segment to which dos loaded us... but you *can* swap 'em back
and forth.

I'd *prove* it to ya, but I hate to reboot. :)

Near the end of Herman's "FLAT_tsr", I added some code, commented out in
what I posted:

..
pop fs
pop gs          ; Restore registers

;        mov al, 'X'
;        int 29h

I know calling ints in an IRQ handler is iffy, but this seems to work.
If you don't see an "X" at all, you were already in "Flat Real Mode: (I
really prefer "relimited real mode" as a descriptive name). Some
versions of himem.sys leave us with 4G-1 limits (!), so this is common.
If you see more than one "X", something (IRQ handler?) has set our
limits back to 0FFFFh, an SOE has triggered and the "workaround" was
necessary. I've never seen this, but I tend to run "mature" hardware.

(carefully avoiding any mention of A20 - I let himem.sys deal with that)

If I can get in the mood to reboot to dos, I'll work some more on that
"challenge" we were discussing in a.l.a. - is it faster than Windows?

Best,
Frank

Am Thu, 21 Feb 2008 18:49:12 +0100 schrieb Wolfgang Kern:

>  Dirk Wolfgang Glomp wrote:
> 
> 
>
> I cannot image that IRQs can work while in Unreal mode.

No problem with himem.sys, ramdisk, mousedriver, cdromdriver, reloading
any segmentregister, enable all IRQ, using softints and adress the hole
4GB. It is only a problem to use memmorymanager like emm386.exe.
 
> 
> do 
>
> One problem is that the CPU actually switches between RM/PM when CS is
> reloaded, the trick to set data-segment registers to flat/unlimted,
> right after b0(CR0) is set, works only until CS become altered.

Yes, the only way to switch into PM is to set b0(CR0) and altering CS.

> So the final IRET in any IRQ-handler (timer,key,mouse...) will do this
> unwanted mode transition (turning BigReal/UnReal into PM).

I donīt believe that an IRET can swap from RM/UnrealM into PM (and back).

> Another thing to assume is that RM IRQ-handlers may temporary reload
> DS/ES/.. and so reset the limit to 64KB again.

The first two things that i do after switching to Unrealmode, is to enable
IRQs and load the unlimited DS with the adress of my Datasegment.

> There are some workarounds for this problems, like what Frank posted,
> but an easier way is to disable IRQs for short periods or use only
> FS and GS for flat-addressing, these two are rare used in plain DOS.

There isnīt any problem when i unlimit only DS and enable IRQs in the
Unrealmode.

Dirk

Frank Kotler wrote:

[...about Unreal/Bigreal]
 

> Don't have to imagine it. Run the code!

I checked it out with my own code a few minutes ago:

My old AMD DX486 always resets the segment limits to RM bounds
on FARcall/jump and IRET, but I'm really surprised that K7,K8 and
also an old Celeron (could't check on AMD64 yet) keep the entered
limits without further notice.

And because my OS were once written for 486, without resetting RM-limits,
it actually remain in Unreal mode whenever it enters RM  :)

So YES. Dirk is right on this one and it seem to work without problems.
only my debugger seems a bit , because it truncates the address
to 16-bit in "real"-mode and I have no idea how to tell the difference.

... sorry for the confusion.

> I'd *prove* it to ya, but I hate to reboot. :)

Thanks, done it myself already ;)

...
> If I can get in the mood to reboot to dos, I'll work some more on that
> "challenge" we were discussing in a.l.a. - is it faster than Windows?

Would be interesting to compare Linux against windoze on this one,
both are 'supported' with vendor specific HW-accellerators.

__
wolfgang

Dirk Wolfgang Glomp wrote:

[...]
I checked it out and you are right!
more details in my answer to Frank.

__
wolfgang

"Wolfgang Kern" <spamtrap@crayne.org> wrote in message
news:fpmg43$ssi$1@newsreader2.utanet.at...
>
> Frank Kotler wrote:
>
> [...about Unreal/Bigreal]
> 
> 
>
> I checked it out with my own code a few minutes ago:
>
> My old AMD DX486 always resets the segment limits to RM bounds
> on FARcall/jump and IRET, but I'm really surprised that K7,K8 and
> also an old Celeron (could't check on AMD64 yet) keep the entered
> limits without further notice.
>

While you're experimenting with "undocumented" modes, have you tried Rick
Hohensee's "Forreal" mode:

http://groups.google.com/group/comp...cd0239969?hl=en
http://groups.google.com/group/comp...69d559d6c4fdaf3
http://groups.google.com/group/linu...3f852603a32582c
http://groups.google.com/group/linu...616fa7d85?hl=en

Is it for real?  ;-)


RP

Am Fri, 22 Feb 2008 13:44:06 +0100 schrieb Wolfgang Kern:

> Dirk Wolfgang Glomp wrote:
>
> [...]
> I checked it out and you are right!
> more details in my answer to Frank.

Mhm.

Dirk

Rod Pemberton  wrote:

[...about Unreal/Bigreal]

> While you're experimenting with "undocumented" modes, have you tried Rick
> Hohensee's "Forreal" mode:
>
> http://groups.google.com/group/comp...cd0239969?hl=en
> http://groups.google.com/group/comp...69d559d6c4fdaf3
> http://groups.google.com/group/linu...3f852603a32582c
> http://groups.google.com/group/linu...616fa7d85?hl=en
>
> Is it for real?  ;-)


I may use other names for the available mode variants, but my OS really
is a mix of 16/32 bit code in unprotected flat mode and can 'call'
16-bit RealMode BIOS routines without problems, even I figured just
yesterday that it's in UnReal mode instead of trueRM ;)

But I use only two sets of identical working IRQ-handlers for RM-16
and PM32 and disable IRQs for the short intermediate states.

Ricks posts show that I'm not the only HEX-freak, but I avoid octals.
__
wolfgang

"Wolfgang Kern" <spamtrap@crayne.org> wrote in message
news:fpp2au$ugj$1@newsreader2.utanet.at...
> Rod Pemberton  wrote:
> [...about Unreal/Bigreal]
>
> even I figured just
> yesterday that [my OS is] in UnReal mode instead of trueRM ;)
>

Does this affect your 486DX results w/IRET etc.?


RP

Rod Pemberton  wrote:
 

> Does this affect your 486DX results w/IRET etc.?

No it didn't affect it at all [on this very early AMD 486DX50],
and I'm surprised that later CPUs keep the limits in 16-bit RM.
I once read in the manuals that segment limits are hardwired
to 64K for RM, but x86 design seem to have changed meanwhile.

__
wolfgang

Dirk Wolfgang Glomp wrote: 
>
> I didnīt know any normal DOS-IRQ that goes to PM, so only memmorymanager d
o
> that?
>

You don't know what the BIOS does behind the back of either DOS or
anything else.  In particular, if the hardware requires access to high
memory (as some disk and network controllers do these days), you have to
go to PM.

-hpa