Here is a write up about detecting Super386 CPU:
https://corexor.wordpress.com/2015/12/05/calling-ct-scall-safely/

The code has been developed using FASM and can be used as a base for other testing purposes.

Thank you for this fascinating information! Do you have an access to actual Super386 CPU? I would love to find out whether it supported the 32-bit code in real mode. As far as I know, the Cyrix clones did not, but I had no chance to test this with a wider variety of 386 clones and variants.

Also, I quickly adapted this source to fasm g, because with the 386 macros I have there it is easy to implement such new instruction with actual arguments. I'm attaching it with the full set of macros needed to assemble it with fasm g (even though most of them come with the official fasm g package anyway). Perhaps you may find this approach useful when testing undocumented instructions.

Unfortunately I don't have an access to the real hardware, but the code has been tested on it thanks to Michal Necasek of os2museum fame. Please contact him through his blog and I guess he will be more than helpful.

As for the code I'm glad you liked it and it has some use for fasm g Now you've forced me to take a better look at it. I'm developing more advanced code base on Super 386 experiences. Despite 32-bit code in real mode possibility Super 386 supported something that looks like advanced (sorry for simplification) SMM clone. The whole story is amazing and fascinating indeed.

I don't know whether I got the order of operands right for the "scall" macro, it might be r/m for the destination instead of source. Do you know more about this instruction? Still, the macro is very easy to tweak if you needed.

Didn't have time to really peek at your code (something planned for evening today), but the 3rd byte is r/m following Intel encoding.

Yes, I knew that, but that third byte may encode either the "r/m,r" or "r,r/m" syntax, it's just about switching the order of operands. In this program the actual instruction is "scall eax,eax" so this does not matter. But if you wanted to try instruction with two different operands, the order would be important. You may need to switch the "dest" and "src" arguments in macro if my initial choice was wrong.

Sorry for misunderstanding your initial post. You are right. I believe the initial setting is correct one.

As a side note I am writing new utility for detecting undocumented opcodes. Adding switching between different strange modes would be a next obvious stop, but at the moment I don't have a time for it.

The problem is that for testing you actually need a lot of original, not virtualized hardware. Emulators for obvious reasons fails. For example when I've run undoc from Undocumented PC under DOSBox it makes it closing down almost immediately.