3 ms·

How did you figure this out? I'll keep my eyes open for this in the microcode.

by kens 6y ago

kiwidrew 6y ago
I was inspired by a post from Raúl Gutiérrez Sanz [1] that described some of the undocumented 8086 opcodes, and was tantalizingly titled "Part I". Unfortunately it seems that Parts II and III were never posted. I had also seen a comment (which I cannot find at the moment) describing the behaviour of LEA r16, m16 when it's given an r16 source operand (so the mod-rm byte has mod=11): the value loaded into the destination register is the value of the internal "IND" register, i.e. whatever memory address the CPU had most recently calculated. So I tried all of the undefined mod-rm encodings (especially the instructions where the 3 'reg' bits encode a sub-opcode) and mostly just found a bunch of aliases for existing instructions. But the FE and FF opcodes -- which encode JMP and CALL -- would randomly crash my test code in strange and beautiful ways. Single-stepping the execution of the opcode would crash the DOS 2.1 version of DEBUG.COM, so I ended up writing my own minimal INT1 handler to capture the value of CS:IP immediately after the malformed JMP or CALL, dump it to the screen, and then restore a sane CS:IP before exiting single-step mode. My hypothesis (from a close reading of the 8086 patent) is that the group decode ROM marks which opcodes have a mod-rm byte and the microcode has a sort of subroutine call (triggered by mod != 11) that calculates the EA and leaves the result in the hidden temporary registers before falling through to the instruction-specific microcode. Skip that subroutine (using mod=11) and interesting things happen. [1] http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/ http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i...
- billforsternz 6y ago
  Great work. I used to keep the MSDOS 2.11 version of debug.com too. All the debug.com goodness in a tiny .com file compared to bloated more recent debug.exe versions. Of course you had to patch it (with debug) to stop it exiting immediately due to the wrong OS version.

How did you figure this out? I'll keep my eyes open for this in the microcode.

by kens 6y ago

How did you figure this out? I'll keep my eyes open for this in the microcode.

I was inspired by a post from Raúl Gutiérrez Sanz [1] that described some of the undocumented 8086 opcodes, and was tantalizingly titled "Part I". Unfortunately it seems that Parts II and III were never posted. I had also seen a comment (which I cannot find at the moment) describing the behaviour of LEA r16, m16 when it's given an r16 source operand (so the mod-rm byte has mod=11): the value loaded into the destination register is the value of the internal "IND" register, i.e. whatever memory address the CPU had most recently calculated. So I tried all of the undefined mod-rm encodings (especially the instructions where the 3 'reg' bits encode a sub-opcode) and mostly just found a bunch of aliases for existing instructions. But the FE and FF opcodes -- which encode JMP and CALL -- would randomly crash my test code in strange and beautiful ways. Single-stepping the execution of the opcode would crash the DOS 2.1 version of DEBUG.COM, so I ended up writing my own minimal INT1 handler to capture the value of CS:IP immediately after the malformed JMP or CALL, dump it to the screen, and then restore a sane CS:IP before exiting single-step mode. My hypothesis (from a close reading of the 8086 patent) is that the group decode ROM marks which opcodes have a mod-rm byte and the microcode has a sort of subroutine call (triggered by mod != 11) that calculates the EA and leaves the result in the hidden temporary registers before falling through to the instruction-specific microcode. Skip that subroutine (using mod=11) and interesting things happen. [1] http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/ http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i...

billforsternz 6y ago
Great work. I used to keep the MSDOS 2.11 version of debug.com too. All the debug.com goodness in a tiny .com file compared to bloated more recent debug.exe versions. Of course you had to patch it (with debug) to stop it exiting immediately due to the wrong OS version.