Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

indirect far jmp - calling old INT problem (Developers)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 15.05.2012, 20:13

> This only works if you restore the flags from [bp+6] into the actual flags
> first, and in that case you'll re-enable TF and IF (if set in the saved
> flags word) too early - before even calling the ROM BIOS's handler, here.
>
> Edited: Actually I did some tests just now because I wasn't sure, and if
> you do a popf (setting TF) right before an int instruction, then it will
> trap only after the int has been called. (Verified in Real and (JEMM's)
> Virtual 86 Mode on my machine.) I don't know/am not sure that the same is
> true of interrupts and IF respectively though.
>
> Then, of course, it would still notionally trap/interrupt too early (ie
> before popping bp in your above suggestion, instead of after/before the
> caller's next instruction), but you already know that.
I'm not sure the TF isn't being "honored" before the INT is being issued, though that's possible (I know there are delays in exactly when an IF change takes effect, but am not sure about TF). When the INT 85h is issued, the CPU automatically tampers with TF & IF and the ISR will never have TF set on entry, no matter what it was set to when the INT was issued. There is the potential that the POP BP and the RETF 2 will run with TF set, but that shouldn't actually hurt anything (though I suppose it could potentially confuse the debugger that set the TF). The state of IF during the few instructions after the INT returns shouldn't hurt anything, either.

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22762 Postings in 2122 Threads, 402 registered users (1 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum