Re: A20 Address line - XMS issue

Re: A20 Address line - XMS issue

[Stas Sergeev]

Hello.

S.Gopi wrote:
> not possible and I was advised to use XMS and EMS settings available 
> under DOSEmu. But I read from FAQs is that I cannot use them if my 
> program uses VCPI
Not "them", you can't use *dosemu* if
your program uses VCPI. Use bochs
instead. The reason is already described
in the nearby message.

> or some other method to access high memory access.
Not exactly. XMS and EMS are both
supported so you can use them for
accessing a high memory. DPMI is
also supported (16bit and 32bit)
so that you can run your programs
in protected mode.

> after some quick hack into dos code I 
> found that DOSEmu is explicitly disabling A20 line and denying any 
> further interrupt calls on that (i guess it is int15,0x87 and 0x88)
> May i know why is it so?
I think it is because there is no
use to control a20 under dosemu.
It is emulated however, so I think
dosemu may not be so picky about
that.

> If DOSEmu can allow these interrupts then 
> programs like himem.sys can use of this
himem uses so called "Big Real Mode".
To enable this mode it must be started
from real mode. himem cannot start in v86
by any means.

> and provide the memory manager suppor
Internally provided by dosemu.

> with VCPI support etc.
himem have nothing to do with VCPI.

> Is there any technical difficulty or 
> memory blocking issues with this or it is disabled for some anonymous 
> reasons.
A20 emulation was implemented much
later than an xms support, I think
this is a reason why that emulation
is not fully used.

> Is there any alternative way for this.
Internal XMS support of dosemu is a
good alternative to himem.
If you have the program that uses
int15/ah=0x87 for memory transferrs
and that fails under dosemu, then I
think this can be fixed, but I need
this program to expirement with.

Re: A20 Address line - XMS issue

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> IIRC himem uses Big Real Mode for the 386, LOADALL for the 286
Yes, but 286 is a bit out of
the scope:)

> and int15
> if (BRM/LOADALL) fails.
It checks the PE bit of cr0 before
trying BRM, and if it is set, it
does int15/ah=0x87:
---
smsw    ax
shr     ax, 1                           ; Protected mode?
jc      MEM3_MoveBlock                  ; if so, use int 15h
---

However int15/87h executes in protected
mode and requires a pointer to GDT as
a parameter, so again, I have a very big
doubts it can work in v86:
---
; MEM3_MoveBlock
;       Set up GDT and call int 15h Move Block
[]
mov     ah, 87h         ; Block Move - Assumes protect
int     15h             ; mode code will allow interrupts
---
So again, whoever hooks int15, must either
have a ring0 access to set up the GDTR for
that GDT or, probably, it is also possible
to just evaluate the necessary addresses
from that GDT and do the transfer from
within the ring3 (taking into an account
also bases, access rights and all the other
info from that GDT) but then who told that
this can't work under cpu-emu?:)

Re: A20 Address line - XMS issue

[Bart Oldeman]

On Sat, 7 Dec 2002, Stas Sergeev wrote:

> However int15/87h executes in protected
> mode and requires a pointer to GDT as
> a parameter, so again, I have a very big
> doubts it can work in v86:

What I meant is that DOSEMU itself could do int15/87h.
It would just have some virtualized raw extended memory where this
function copies to/from.

The GDT that ES:SI points to would just be used as a block of information,
rather than as a real GDT.

int15/87 now simply does:

  else {                        /* AH = 0x87 */
    x_printf("XMS int 15 block move failed AX=0x%04x\n", (u_short)REG(eax));
    LWORD(eax) &= 0xFF;
    HI(ax) = 3;                 /* say A20 gate failed */
    CARRY;
  }

Bart

Re: A20 Address line - XMS issue

[Stas Sergeev]

Hello.

Bart Oldeman wrote:
> HIMEM.SYS might be able to
> run in DOSEMU if DOSEMU would implement int 0x15/0x87 to copy extended
> memory though.
It can't.

> HIMEM.SYS might be able to
> run in DOSEMU if DOSEMU would implement int 0x15/0x87 to copy extended
> memory though.
Real mode is an ultimate requirement
for himem to work. You can't set up
the Big Real Mode from within v86.
Here is the source:
http://honors.tntech.edu/~will/fileformat.virtualave.net/programming/himem/xm386.asm
Here is the relevant part:
---
mov     bx, descRealBig - OurGDT ; Special 4Gb selector
lgdt    qword ptr cs:[GDTPtr]

mov     eax, cr0
or      al,1
mov     cr0, eax         ; Go into Protected Mode
                          ; NOTE: NMIs will kill us!!!
---
Both "lgdt" and "mov cr0" are priviledged.

Re: A20 Address line - XMS issue

[Bart Oldeman]

On Sat, 7 Dec 2002, Stas Sergeev wrote:

> Bart Oldeman wrote:
> > HIMEM.SYS might be able to
> > run in DOSEMU if DOSEMU would implement int 0x15/0x87 to copy extended
> > memory though.
> Real mode is an ultimate requirement
> for himem to work. You can't set up
> the Big Real Mode from within v86.

IIRC himem uses Big Real Mode for the 386, LOADALL for the 286 and int15
if (BRM/LOADALL) fails. Maybe I'm wrong here, but surely 286's have
himem but not BRM (aka FRM).

At least FreeDOS HIMEM/FDXMS can use int15 instead of protected mode if
the user wants it or pm is privileged.

Bart

A20 Address line - XMS issue

[S.Gopi]

Hi all,

   First of all sorry if I am talking about something which is very 
silly and stupid topic.

I want to use HIMEM.SYS under DOSEMU with FreeDOS. I heard that this is 
not possible and I was advised to use XMS and EMS settings available 
under DOSEmu. But I read from FAQs is that I cannot use them if my 
program uses VCPI or some other method to access high memory access.

I tried loading HIMEM.sys and it bounced back with error message
'Unable to Control A20 Line', after some quick hack into dos code I 
found that DOSEmu is explicitly disabling A20 line and denying any 
further interrupt calls on that (i guess it is int15,0x87 and 0x88)

May i know why is it so? If DOSEmu can allow these interrupts then 
programs like himem.sys can use of this and provide the memory manager 
suppor with VCPI support etc. Is there any technical difficulty or 
memory blocking issues with this or it is disabled for some anonymous 
reasons.

Is there any alternative way for this.

Thank you and sorry if this has been discussed already,
gopi

Re: A20 Address line - XMS issue

[Reinhard Karcher]

On Fri, Dec 06, 2002 at 08:23:52PM +0530, S.Gopi wrote
> 
> May i know why is it so? If DOSEmu can allow these interrupts then 
> programs like himem.sys can use of this and provide the memory manager 
> suppor with VCPI support etc. Is there any technical difficulty or 
> memory blocking issues with this or it is disabled for some anonymous 
> reasons.
> 
As VCPI uses priveledged instructions, which are reserved for the kernel,
you can't use VCPI. DPMI is the method to use 32-bit programs.

Reinhard

Re: A20 Address line - XMS issue

[Bart Oldeman]

On Fri, 6 Dec 2002, S.Gopi wrote:

> I want to use HIMEM.SYS under DOSEMU with FreeDOS. I heard that this is
> not possible and I was advised to use XMS and EMS settings available
> under DOSEmu. But I read from FAQs is that I cannot use them if my
> program uses VCPI or some other method to access high memory access.

HIMEM.SYS services are *provided* by DOSEMU. HIMEM.SYS might be able to
run in DOSEMU if DOSEMU would implement int 0x15/0x87 to copy extended
memory though. However it's a fairly pointless exercise unless you really
need some very special use.

> I tried loading HIMEM.sys and it bounced back with error message
> 'Unable to Control A20 Line', after some quick hack into dos code I
> found that DOSEmu is explicitly disabling A20 line and denying any
> further interrupt calls on that (i guess it is int15,0x87 and 0x88)

a) dosemu does not implement int15/0x87
b) dosemu emulates A20 through these calls
   1. XMS driver calls ah=3/4/5/6/7.
   2. the relevant I/O port (keyboard related).
   using a paging technique. The XMS driver API (in real DOS this
   API is provided by HIMEM or FreeDOS FDXMS) has been in DOSEMU
   for ages. The port technique became necessary when we found out that
   Windows ME DOS bootdisks use that.

> May i know why is it so? If DOSEmu can allow these interrupts then
> programs like himem.sys can use of this and provide the memory manager
> suppor with VCPI support etc. Is there any technical difficulty or
> memory blocking issues with this or it is disabled for some anonymous
> reasons.

himem.sys might run, but VCPI support is out of the question without CPU
emulation; VCPI needs ring-0 access.

Bart

Re: A20 Address line - XMS issue

[S.Gopi]

--- Bart Oldeman <oldeman@math.ohio-state.edu> wrote:
> 
> HIMEM.SYS services are *provided* by DOSEMU.
> HIMEM.SYS might be able to
> run in DOSEMU if DOSEMU would implement int
> 0x15/0x87 to copy extended
> memory though. However it's a fairly pointless
> exercise unless you really
> need some very special use.

it looks fine, if dosemu can emulated these interrupt
calls and do memory paging in the protected mode
itself with given virtual memory(something like what
is being done in the XMS now) it would make it
possible to use HIMEM.sys
> 
> 
> a) dosemu does not implement int15/0x87
> b) dosemu emulates A20 through these calls
>    1. XMS driver calls ah=3/4/5/6/7.
>    2. the relevant I/O port (keyboard related).
>    using a paging technique. The XMS driver API (in
> real DOS this
>    API is provided by HIMEM or FreeDOS FDXMS) has
> been in DOSEMU
>    for ages. The port technique became necessary
> when we found out that
>    Windows ME DOS bootdisks use that.
> 
> 
> himem.sys might run, but VCPI support is out of the
> question without CPU
> emulation; VCPI needs ring-0 access.
fine, what is the effort that needs to be put on this,
I mean is that possible to do it with current dosemu
distribution itself with little bit of code hack. I
would like to do it since this is very much important
for the project i am involved in.
gopi


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com