News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

generation of INT 0D in real mode

Started by sancho1980, November 26, 2006, 02:13:13 PM

Previous topic - Next topic

sancho1980

hi

i have here a piece of code.
it's written for nasm
it demonstrates how to switch to pm and back
i more or less understand what it does; but one thing i dont get: the code changes the isr of interrupt INT 0D
please have a look at line 114; it says:

; Try using a 32-bit address in real mode. Depending on "where the CPU's
; been", this may or may not cause interrupt 0Dh.
;
   mov ebx,0xB809A         ; ES still 0
   mov byte [es:ebx],'R'      ; 'R' in upper right corner of screen

Can someone explain this to me? I don't understand this: "depending on where the cpu's been", this may or may not cause interrupt 0Dh

What does he want to say "WHERE the cpu has been"? Where can it have been??? And why would this instrction cause an interrupt?

This seems even stranger to me given the fact that in the lines before, interrupts were turnt off!!!

Thanx,

Martin

[attachment deleted by admin]

japheth


> What does he want to say "WHERE the cpu has been"? Where can it have been???

Possibly it is not meant geographically...

Since the articel covers unreal mode I guess he wants to test if "unreal mode" is already on ... that is, the segment cache for register ES is 32-bit with a limit of FFFFFFFFh.

If ES limit is still 16-bit FFFFh, this is one of the rare occasions where an exception 0Dh (GPF) is generated in real-mode.  That's also the reason why Int 0Dh is hooked. The original handler for Int 0Dh usually will not expect the error code pushed onto the stack, which then results in a crash at the IRET.




sancho1980

ok thank you
i think i got it
while were at it
can you explain to me what the following 3 lines in the new isr 0Dh are supposed to do:

pop ax            ; point stacked IP beyond...
add ax,5         ; ...the offending instruction
push ax

as far as i understand, the last thing pushed on the stack before invoking the isr is the return address but: this is a trap, so the return address should point AFTER the offending instruction..so it should be possible to return from the isr without any modification of the last values pushed on the stack..see what i mean?

thanx

martin

japheth


> this is a trap, so the return address should point AFTER the offending instruction..

exception 0Dh is not a trap, it's a fault.

Did you run the code already? Does it work?

sancho1980

Quote from: japheth on November 26, 2006, 07:53:05 PM

> this is a trap, so the return address should point AFTER the offending instruction..

exception 0Dh is not a trap, it's a fault.

Did you run the code already? Does it work?

Ah, ok that's why!
I ran the code
It doesnt work if I comment the lines out but now I know why
probably because the label in the code is "trap"..so thats why i thought its a trap
btw, how do i know whether an exception is a trap, fault or abort? is there a list for it?
thanx,
martin