Reputation: 40982
I was looking at some snippet and saw these lines (part of the .com
file):
DB 66;
CALL D59C:C2C0;
INT 69
MOV SI, C8C6
What does INT 69
do?
I didn't find anything online, and I didn't find anything here as well:
The weird thing is that there is no moving any value to AH
or AL
before the INT 69
.
EMU8086. 8086 microprocessor emulator. Integrated disassembler.
Upvotes: 0
Views: 766
Reputation: 62048
Assuming that the given code is meant to execute in 16-bit mode and encodes consecutive instructions, I have a different interpretation of it.
DB 66
is the operand size prefix
. In 16-bit mode it tells the CPU to interpret instruction operands as 32-bit instead of 16-bit. So, the CALL
instruction will be interpreted as CALL 16-bit selector:32-bit offset
instead of CALL 16-bit selector:16-bit offset
. The "missing" 2 bytes of the address are the INT 69
"instruction".
The effective code is then this:
CALL 69CD:D59CC2C0
MOV SI, C8C6
But that doesn't make much sense to me because a call with such an address (offset > 0FFFFh) will cause an exception. What kind of code is that?
Upvotes: 3
Reputation: 46998
Assuming that everything is in hex here, if this is 16-bit code then we have:
66 DB 66
9A C0 C2 9C D5 CALL D59C:C2C0
CD 69 INT 69
BE C6 C8 MOV SI, C8C6
But 0x66
is the operand size override prefix (presumably just not disassembled properly here), which (in 16-bit code) causes the following instruction to take a 32-bit operand instead of a 16-bit one. So this code is actually:
66 9A C0 C2 9C D5 CD 69 CALL 69CD:D59CC2C0
BE C6 C8 MOV SI, C8C6
A far call to a fairly random-looking 16:32 bit absolute address from 16-bit code doesn't look very plausible to me.
So I would guess that this is actually data, rather than code...
Upvotes: 9
Reputation: 12815
A search for x86 interrupts yielded this list, presumably written by one Ralf Brown. If it's what I believe it is, this is the definitive list of interrupts from a generation ago. Brings back memories.
Upvotes: 2