Hi,

In the doc for Pmode

3.2 - Chaining to real mode:
----------------------------

If you don't set the real mode IRQ callback for a particular IRQ, chaining
to that IRQs real mode handler is as easy as using INT 33h with the
appropriate interrupt number. But you probably will set the callbacks. In
which case, if you use INT 33h, it will just go to the protected mode IRQ
handler. And if this INT 33h call was from the protected mode IRQ handler,
well, lets just say infinite loop. If you have the callback set, and you wish
to chain (why bother?), you must make the address of the real mode IRQ handler
available to a real mode far routine that will call that handler as an
interrupt routine. You should call this real mode routine with INT 32h from
protected mode to do the IRQ chaining.

I need more insights into chaining to msdos interrupts from my protected mode interrupts?


2.1 - Calling real mode:
------------------------

From your protected mode code you can call real mode interrupts and routines
using protected mode interrupts set up by PMODE for this purpose. You pass
registers to the real mode interrupt or routine through the use of virtual
registers, which are just memory images of the values to be set for those
registers in real mode. There are virtual registers for EAX, EBX, ECX, EDX,
ESI, EDI, EBP, DS, ES, FS, and GS. The virtual registers for AL, AH, and AX
share the appropriate memory space within the virtual EAX reg. Notice that
there are no SS, ESP, CS, and EIP registers. CS:EIP is taken from the real
mode interrupt vektor table for interrupt calls, and passed in the real CX:DX
registers for a procedure call. SS:ESP is set up by PMODE.

An INT 32h instruction in protected mode calls a real mode procedure. The
real CX:DX registers are the seg:off of the real mode procedure. The real mode
procedure must return with a RETF. The interrupt enable flag is preserved
across the call to real mode, but not back. After the INT 32h the IF flag will
be the same as before. The real carry, zero, aux, parity, sign, and overflow
flags will be passed back from the real mode routine unchanged. The real CPU
registers will be set to the values of the virtual registers for the real mode
routine. The return values of the routine will be stored back into the virtual
registers. The actual CPU registers will be unchanged in protected mode.

An INT 33h in protected mode will call a real mode interrupt handler. AL is
the interrupt number you want to call. The interrupt flag is disabled for the
real mode interrupt handler just as it is in real mode. Other than this, INT
33h works just like INT 32h with respect to virtual registers and the real
flags passed back from the handler.


I have quite a few int 33 calls in this real mode app I'm converting
and they all access INT 33H - MS MOUSE calls.

Do I use the Pmode int 33h to get to the INT 33H - MS MOUSE calls?

If I am converting:

mov ax,1 ;Enable mouse pointer
int 33h ;

To

mov v86r_ax,1 ;
mov al,33h ;
int 33h ;

Is this correct?


Also I need to convert this section

MOV DX,OFFSET MOUSE_INTERCEPT ;EXCHANGE INTERRUPT SUBROUTINES
MOV CX,47 ;
MOV AX,14H ;
INT 33H ;
MOV MOUSE_LO,DX ;
MOV MOUSE_HI,ES ;
MOV MOUSE_MK,CX ;


Into this, but I need help

MOV v86r_dx, OFFSET MOUSE_INTERCEPT ;EXCHANGE INTERRUPT SUBROUTINES

How do I turn the code32 offset ( MOUSE_INTERCEPT ) into one that is accepptable for the dos interrupt?

MOV v86r_cx,47 ;
MOV v86r_ax,14H ;
mov al,33h ; <-- Is this right?
int 33 ;
mov MOUSE_LO,v86r_dx ;
mov MOUSE_HI,v86r_es ;
mov MOUSE_MK,v86r_cx ;

Thanks all.

JohnU789
Posted on 2004-11-10 15:43:46 by JohnU789
MOV DX,OFFSET MOUSE_INTERCEPT ;EXCHANGE INTERRUPT SUBROUTINES
MOV CX,47 ;
MOV AX,14H ;
INT 33H ;
MOV MOUSE_LO,DX ;
MOV MOUSE_HI,ES ;
MOV MOUSE_MK,CX ;

Into this, but I need help

MOV v86r_dx, OFFSET MOUSE_INTERCEPT ;EXCHANGE INTERRUPT SUBROUTINES

How do I turn the code32 offset ( MOUSE_INTERCEPT ) into one that is accepptable for the dos interrupt?

I noticed in the Pmode doc

1.1 - Usage and DOS:
-- ------------------

When you call real mode DOS interrupts, or any real mode procedure that
expects a buffer, you will have to make sure that buffer is in low memory.

Do you think it would be wise to use a use16 segment for the app's old data and then it could all be accessed from either 16 bit or 32 bit code?

Thanks all.
Posted on 2004-11-10 22:36:04 by JohnU789
Rules for this forum section state that you should ask win32asm questions here...and NOT DOS Pmode questions

I think there is an DOS section or and Pmode/OS section for such things

Aslo making multiple threads withe the same issue is not a good idea :D
Posted on 2004-11-10 22:48:50 by BogdanOntanu
I sorry about the double topic posting.

However,

PMODE.ASM is a small piece of assembly code which is intended to allow for easy 32bit flat protected mode coding in assembly.

In reality it is win32.asm questions I'm asking.

I could easily include some windows headers and libs and then call win32 functions using Pmode programming.

JohnU789
Posted on 2004-11-10 23:31:54 by JohnU789
> I could easily include some windows headers and libs and then call win32 functions using Pmode programming.

AFAIK your code is running in a dos box and the win32 API is not available.

> Do you think it would be wise to use a use16 segment for the app's old
> data and then it could all be accessed from either 16 bit or 32 bit code?

That's not the point. you will have to allocate conventional memory
so the memory can be accessed by code running in protected mode and real mode.

Are you really stuck to the pmode extender? I don't think this is a good decision.
Posted on 2004-11-11 00:41:41 by japheth
No, not really stuck. I just wanted to test some ideas I have for this app. I wanted to make it for win32 eventually. I thought I could just easily convert it to Pmode and this would give me the extra memory I need to test out the ideas I have.

The stuff I would be testing would eventually go into the app, so it wouldn't be a waste of time, but if conversion into Pmode is too difficult then that would be a waste of time.

This is why I was asking questions before I jump into the converting.

Thanks.

JohnU789
Posted on 2004-11-11 06:08:49 by JohnU789
the pmode extender with its int 33h (and int 32h IIRC) interface is not the best choice for a conversion. Much easier are extender simply based on DPMI, like WDOSX, DJGPP or CauseWay. All are free, binaries and source. I once wrote another extender, HX, which is free as well and offers a Win32 emulation, which one can use or not (same as with WDOSX), so a final migration to Win32 should be fairly easy.
Posted on 2004-11-12 01:15:29 by japheth
Yes, Pmode 2.51 interface does seem clumsy with its v86r registers.
I download your extender, HX and DOS/32 Advanced DOS Extender
Version: 7.2. I am looking these two over now.

Thanks for the tip

JohnU789
Posted on 2004-11-12 10:38:57 by JohnU789