🚀 go-pugleaf

In some article, it was written:
+}  In my Infoplus program, the 286/386/486 are detected by trapping the
+}invalid opcode interrupt, and then trying instructions. For the 486, I use
+}XADD DX,DX. This is new on the 486, and exchanges the registers before
+}doing the addition.

Hmm.  Sounds like my algorithm!

+}  For the 386, I now use MOV EDX,EDX, which is 32-bit do-nothing! (It used
+}to use an instruction that read some special registers. This caused major
+}problems with most EMS emulators!)

Wow, this can't be coincidence!

+}  For the 286, it tries the SMSW DX instruction (whatever that does.)

Ok, about now I got a little hot, until I read the next line.
(BTW, "SMSW DX" is the '286 version of "MOV EDX,CR0").

+}  The code come from a program by Robert Collins

Thanks for the credit.

+Unfortunately, your program will fail miserably on my system (and about a
+million others), because I am running QEMM-386.  QEMM runs in protected mode
+with DOS in virtual-86 mode.  Any invalid opcode exception that your
+program generated invokes the QEMM exception handler, NOT YOURS.  And the
+QEMM exception handler gives the choice of terminating or rebooting.  I
+expect similar behavior from 386^Max, CEMM, AllCharge386, MICEMM, ....

Ask yourself.  Is the the CORRECT behavior for QEMM-386, et al?  Or should
these programs turn control of invalid opcodes to the user's program?

>From the Intel "80386 Programmer's Reference Manual" PN 230985-001 (first
printing), on page 2-20 comes the following quote:  "Invalid opcodes may
be used by some applications to extend the instruction set.  In such a case,
the invalid opcode exception presents an opportunity to emulate the opcode."

But Intel found that software writers were REALLY taking advantage of this
"feature" and as a result ran into some problems.  Intel found that some
programmers were using invalid opcodes that didn't generate an invalid
opcode exception.  HUH!?  Intel has a list of reserved, undocumented
opcodes on the '286, '386, and '486 that do something, and obviously won't
generate an invalid opcode exception.  People were attempting to use these
opcodes to emulate CPU extensions.  Intel probably got tired of taking so
many calls on this subject, and removed the abovementioned quote from the
PRM.  The following disclaimer replaced it:  "Intel reserves the right to
enhance future products by using opcodes that are currently defined as
invalid.  Use of invalid opcodes to extend the instruction set may not be
compatible with future Intel products and is therefore discouraged."

But, there is plenty of software that uses this technique.  My CPU
determination subroutine was written for ROM BIOS, and was obviously
not intended to run under protected mode.  But the makers of these
products that put the '386 and '486 in V8086 mode, who don't pass control
of the invalid opcode handler back to the user program, are obviously in
error.	If QEMM fails to do this, it is obviously in error, and will have
numerous compatibility problems with software using this technique.

386MAX does NOT use this technique, and passes control to the user program.
Currently, VM386 does fail, and I called them this morning to explain to
them that they are wrong.  I am awaiting a return call from them.

I hope this resolves some confusion, and puts to rest any "blame" regarding
the use of my algorithm in Virtual 8086 mode.

Robert Collins
Altos Computer Systems