I'm an assembly n00b. And this is for educational purposes only. The assembly code part is from shareware (freeware) version. All the addresses hex-values are hidden intentionally as this is not a patching/hacking guide. Also this part of the code do not alter any shareware version limitations in any way. I don't comment any bytecode hex-values. I only want to understand why this emulator refuses to work with 186 CPU as it claims is capable of.

Here is what I managed to read from Emu386 disassembled machine code. Comments starting with "<-" and ending with "!!!" are added by me:

The DOS version check is simple and clear, and out of the scope. I'm not sure if there's any 186 CPU check along with 286 CPU check condition - rather there's none. I tried to skip 286 check failing by changing "je loc_393" to "jmp loc_393", but then all the CPUs (8088, 8086, 186 etc.) excluding 286 are recognized as "386 or newer" CPU and there's no way to load the emulator on a 186 (or V20/30) CPU after this kind of patching. I don't have an idea if these checks can be easely patched to allow Emu386 execution on 186, V20 and V30 CPUs.

This emulator might be "a killer DOS app", if only had been implemented properly in order to work on V20/30 CPUs (80186 is not a real PC CPU thing even though there are some 80186 based personal computer rarities). Unfortunately there's no further development, support and sales from at least decade ago 🙁 At least it's still pretty usable on 80286 systems.

You can simply change the conditional jump, inverting the condition.

But then, you start with a 186/188 (v20/v30) which is not the same as a 286 (it is a subset), so it may probably be not enough for a reliable EMU386 emulation layer.
But it is theory. Better you do it and test it. There is a chance you could be lucky in some scenarios.

You can easily patch it with HIEW (versions up to 6.87 are for DOS) or QVIEW. There are many more editors for DOS patching, but those are my preferred ones.

BTW, there is still support for 186 and its offspring, as they were generally used in the industrial/embedded sector. One example for a still available and supported product:
http://www.jkmicro.com/flashlite186.html

igully wrote on Yesterday, 01:13:

http://www.jkmicro.com/flashlite186.html

Oh dear, at 33 MHz, it may be the fastest XT-class computer ever - much faster than anything with a V30.

But is that really an XT-class computer?
That would require compatible PIC, DMA, PIT, PPI, BIOS...

Grzyb wrote on Yesterday, 02:24:

Oh dear, at 33 MHz, it may be the fastest XT-class computer ever - much faster than anything with a V30. […]
Show full quote

igully wrote on Yesterday, 01:13:

http://www.jkmicro.com/flashlite186.html

Oh dear, at 33 MHz, it may be the fastest XT-class computer ever - much faster than anything with a V30.

But is that really an XT-class computer?
That would require compatible PIC, DMA, PIT, PPI, BIOS...

It is an SBC that lacks the ISA backplane, but you can use its pinout to build one, as it has all the signals. It has no built-in graphics card. But it has an XT architecture with some extras which are usual in these type of SBC, like watchdogs, extra GPIO, various different types of serial ports, and DOS in some form of flash ROM or DOM. DOS handling is usually done through the serial port: a simple CTTY COM1 and that was it, you had the DOS Prompt at a dummy TTY connected to it.

igully wrote on Yesterday, 01:13:

You can simply change the conditional jump, inverting the condition.

Nope. If "je loc_393" is changed to "jne loc_393", then probably 286 CPU will be detectd as non-286 and all other CPUs will be treated like they're 286 CPUs, which doesn't seem like smart solution for adding the 186 or V20/V30 support. And after this, I have no idea what result will be given by the check for "386 or above" CPU check.

As I wrote, I'm not into x86 or another assembly. I don't know what exactly happens in all these register mumbo-jumbo combinations like "push sp", "pop ax" etc., but I see that "cmp sp, ax" compares the stack pointer "sp" value to the value in "ax" accumulator to determine the condition for 286/non-286 CPU detection and this is still "a complete non-sense" to me 😁

Maybe I will be able to "glue" a patch for proper 286 + 186 and V20/V30 detection at the end 0f the exe-file, if one day I learn some more x86 assembly and how to translate it manually to hex-code...

igully wrote on Yesterday, 01:13:

But then, you start with a 186/188 (v20/v30) which is not the same as a 286 (it is a subset), so it may probably be not enough for a reliable EMU386 emulation layer.
But it is theory. Better you do it and test it. There is a chance you could be lucky in some scenarios.

As far as I could understand, this Emu386 "386 for 286 emulator" simply "translates" the 386 real mode instructions (the ones missing in 286) into a combinations of a 286 real mode instructions (almost all of these are also in 186, V20 and V30, right?) and this way it's more of a software "middle layer" CPU addition/upgrade instead of a full-blown CPU emulator for a CPU of another type/architecture.

igully wrote on Yesterday, 01:13:

You can easily patch it with HIEW (versions up to 6.87 are for DOS) or QVIEW. There are many more editors for DOS patching, but those are my preferred ones.

The hex-editor is not the problem at all. I'm using much more advanced one for Linux, than the old freeware version of DOS HIEW hex-viewer/editor 😉 I've never heard of QVIEW for DOS, but its site is still online and "on paper" it seems like superior thing compared to HIEW. And Sourcer for DOS (works fine in DOSBox) is a great tool for DOS software disassembly/debugging. IDA Freeware versions 4.3 and 5.0 su*ked hard on this emu386s.exe treating it like it was compressed DOS executable while it's not 😁

igully wrote on Yesterday, 01:13:

BTW, there is still support for 186 and its offspring, as they were generally used in the industrial/embedded sector. One example for a still available and supported product:
http://www.jkmicro.com/flashlite186.html

186 CPUs were still produced in the beginning of the new millennium, as they were mostly used in industrial controllers.The main problem is in their general incompatibility with the other PC-XT architecture components. And this is why I consider V30 and V20 CPUs as "better 186s for PC", than the real 186 CPUs.

analog_programmer wrote on Yesterday, 05:39:

igully wrote on Yesterday, 01:13:

You can simply change the conditional jump, inverting the condition.

Nope. If "je loc_393" is changed to "jne loc_393", then probably 286 CPU will be detectd as non-286 and all other CPUs will be treated like they're 286 CPUs, which doesn't seem like smart solution for adding the 186 or V20/V30 support. And after this, I have no idea what result will be given by the check for "386 or above" CPU check.

Ok, I've just tried this simple "je loc_393" to "jne loc_393" change just to confirm that this patching won't work (just like my previous attempt with "je loc_393" to "jmp loc_393"). And it's even worse than I expected. Now all 386 and newer CPUs are detected as incapable to run the emulator giving the message "ERROR: PC/AT with 80186/80286 processor required" instead of the correct "ERROR: Processor is 386 or above" - this is what I expected 😁 And also 286, 186 and 8086 CPUs refuse to run the emulator giving the message "ERROR: Processor is 386 or above" - this is totally unexpected 🤣🤣 So this simple "patch" turned the Emu386 executable into a bunch of useless bytes 😁

As expected - double nope for this "patch".

Now I have some hacky idea on how to replace the entire function for 286 check so support for 186 and V20/30 CPUs to be added (I think I have more than enough "free space" in place of useless shareware "nag screen" subroutine code and string/data), but unfortunately I can't write the new assembly lines nor the bytecode needed.

If you will disassemble to do other changes ,look for B9 12 00 and change to B9 01 00, this remove timer

theelf wrote on Yesterday, 11:12:

If you will disassemble to do other changes ,look for B9 12 00 and change to B9 01 00, this remove timer

Actually there's no need to disable the timer separately. My solution to this is even simpler - bypassing the entire "nag screen" subroutine (including the stupid timer) by shifting of one particular "retn" instruction with three bytes. I may show you my solution with assembly code in PM, 'cause for writing a new subroutine or function validating checks for 186 and V30/20 CPUs I'll need help from someone who's more into x86 assembly 😉

P.S. I don't know if this is the proper place to attach something patched even if the thing is a shareware version i.e. free version of long time abandoned and forgotten (still useful in retro computer scene) software, because of some moderator's "fluid" interpretation and application of the rules concerning such things. Again, the version I'm playing with is free of charge EMU386S.EXE ("S" is for shareware) 1.34 beta 1 shareware/freeware version, which can still be downloaded freely from the archived version of its home site. I have a dosfreakophobia (fear of dosfreaks) in this forum 😁

Now I remember, that once I've been asking our fellow forum member and old BIOSes expert Jan Steunebrink (Chkcpu) something about those old BIOSes and he explained that in Pentiums and newer processors there's an instruction for easy CPU identification, but for the older silicon like 486, 386, 286 etc. there is no such a thing and he uses another techniques in his own CHKCPU utility. Actually his tool properly detects the 186 CPU in DOXBox-X with emulated 186, so at least I know who to ask for help on the assembly code for simple V20/30, 186, 286 and 386(+ newer CPUs) detection.

analog_programmer wrote on Yesterday, 14:11:

V20/30

Looking at the V20 hardware manual at https://archive.org/details/bitsavers_necV20V … ge/n25/mode/1up , there is table 6-1, which lists all the interrupts sources supported by the processor, which does not include an "invalid opcode" exception (INT 6). So the approach used by Emu386 to emulate the 386 processor does not apply to the V20. As far as I know, the V40/V50 does support the invalid opcode exception, I didn't check a data sheet, though. I remember seeing a V40 laptop back in the day that had an handler for INT 6 in the BIOS that printed "INVALID V40 OPCODE TRAPPED" or something along those lines.

mkarcher wrote on Yesterday, 15:42:

Looking at the V20 hardware manual at https://archive.org/details/bitsavers_necV20V … ge/n25/mode/1up , there is table 6-1, which lists all the interrupts sources supported by the processor, which does not include an "invalid opcode" exception (INT 6). So the approach used by Emu386 to emulate the 386 processor does not apply to the V20. As far as I know, the V40/V50 does support the invalid opcode exception, I didn't check a data sheet, though. I remember seeing a V40 laptop back in the day that had an handler for INT 6 in the BIOS that printed "INVALID V40 OPCODE TRAPPED" or something along those lines.

Thanks for the info even it is not in "good news" category! So, is there anything to be done like workaround for this missing interrupt 6 or it will be pointless to patch this "386 emulator" anymore?

Actually I'm not interested in "386 emulator for 186" as I don't consider 80186 CPUs as a "real" PC-XT CPUs, but I sill want a "386 emulator for V20/30".

Hello, at first when I disassembled in ida I thought about skipping the whole message, but then I figured if I’m gonna share it with others, it’s better to leave it and just jump the counter. That way, the author’s data and messages stays visible

If someone don’t wanna see any text, can load it with devload, which is what I do in a bat. Just run devload emu386s.exe >nul and will be a transparent load

analog_programmer wrote on Yesterday, 15:58:

Thanks for the info even it is not in "good news" category! So, is there anything to be done like workaround for this missing interrupt 6 or it will be pointless to patch this "386 emulator" anymore?

Actually I'm not interested in "386 emulator for 186" as I don't consider 80186 CPUs as a "real" PC-XT CPUs, but I sill want a "386 emulator for V20/30".

If your goal is 386 emulation on a V20/V30, you will need a different (and most likely way slower) approach.

The 80186 and up (as does the V40, as confirmed in the mean time by Jo22) automatically jump to the emulator using interrupt 6 if any unhandled instruction (likely a 386 instruction in this use case) is encountered, so all 286 instructions are executed at full speed without emulator inteference. The V20/V30 processor can not do that. The behaviour of the V20/V30 is only specified for the instructions listed in the manuals. Obviously, it will behacve in some way if it encounters an instruction that's not in the manual, but as that way is not documented, it's unlikely that there is a simple way to catch all 386 instructions while executing 186 instructions normally at full speed.

theelf wrote on Yesterday, 16:24:

Hello, at first when I disassembled in ida I thought about skipping the whole message, but then I figured if I’m gonna share it with others, it’s better to leave it and just jump the counter. That way, the author’s data and messages stays visible

If someone don’t wanna see any text, can load it with devload, which is what I do in a bat. Just run devload emu386s.exe >nul and will be a transparent load

I sent you my working solution by PM. It doesn't remove the message in the "frame", but skips the additional "nag screen" with "This message and delay will be dissapear in registered version... blah-blah" and the timer.

mkarcher wrote on Yesterday, 16:42:

If your goal is 386 emulation on a V20/V30, you will need a different (and most likely way slower) approach.

The 80186 and up (as does the V40, as confirmed in the mean time by Jo22) automatically jump to the emulator using interrupt 6 if any unhandled instruction (likely a 386 instruction in this use case) is encountered, so all 286 instructions are executed at full speed without emulator inteference. The V20/V30 processor can not do that. The behaviour of the V20/V30 is only specified for the instructions listed in the manuals. Obviously, it will behacve in some way if it encounters an instruction that's not in the manual, but as that way is not documented, it's unlikely that there is a simple way to catch all 386 instructions while executing 186 instructions normally at full speed.

Yep, but this is not a full 386 CPU emulator and only adds the missing 386 real mode instructions to 286 in a software layer and they can not be executed at full speed as there is a software translation to 286 supported instructions. There's a bunch of old software compiled with flags for 386 CPU that can run fine with this emulator on a 286 machine. I've read some local forums with comments about the V30/20 and some of them claim that these are mostly compatible with 186 and real mode for 286, but of course there's no official documentation to prove/deny this statements. I don't know how slower V30 at 16 MHz will be compared to 286 at 12 MHz, but it will be cool to have an option for 386 real mode software running on V30/20.

I asked, if you see any possibility the missing interrupt 6 to be trapped (like in the V40 laptop's BIOS you mentioned) when the Emu386 runs on V30/20 (if we manage to patch it to run on such a CPUs). Of course the patch for missing INT 6 means more work, but first I want to know if it will be possible at all.

analog_programmer wrote on Yesterday, 17:09:

I asked, if you see any possibility the missing interrupt 6 to be trapped (like in V40 laptop's the BIOS you mentioned) when the Emu386 runs on V30/20 (if we manage to patch it to run on such a CPUs). Of course the patch for missing INT 6 means more work, but first I want to know if it will be possible at all.

First, I don't think there is any trappable response to invalid instructions on the V20/V30, so this approach seems impossible on the V20 and V30.

Furthermore, while I didn't want to search the whole V20 manual for V20 extensions to the 286 real mode instruction set colliding with 386 extensions to the 286 real mode instruction set, I the meantime I remembered that the NEC proprietary REPC / REPNC prefixes use the same opcodes as the 386 FS and GS segment prefixes, and I just verified that indeed, the encoding is identical. So the byte sequence "65 AE" is trapped as invalid opcode on the 80186 and 80286, it is executed as "compare a single byte at [FS:SI] to the single byte at [ES:DI], then increment both SI and DI (FS:; CMPSB)" on the 80386 (and I am confident EMU386 emulates this instruction perfectly), but it is executed as "compare bytes at [DS:SI] to bytes at [ES:DI], increment SI and DI after each byte, decrement CX after each byte, until a byte at DS:SI is found to be bigger than the corresponding byte at ES:DI or CX reached zero (REPNC CMPSB)" by all NEC V-series processors. It does not generate an INT6 on V40 or V50 processors, so EMU386 doesn't get a chance to emulate the 80386 with the same encoding.

This means an 386 emulator based on trapping invalid instructions is not only impossible on the V20/V30 (because they don't trap invalid instructions), but also on the V40/V50, because it misinterprets some 386 instructions as NEC instructions.

mkarcher wrote on Yesterday, 18:13:

First, I don't think there is any trappable response to invalid instructions on the V20/V30, so this approach seems impossible on the V20 and V30.

Furthermore, while I didn't want to search the whole V20 manual for V20 extensions to the 286 real mode instruction set colliding with 386 extensions to the 286 real mode instruction set, I the meantime I remembered that the NEC proprietary REPC / REPNC prefixes use the same opcodes as the 386 FS and GS segment prefixes, and I just verified that indeed, the encoding is identical. So the byte sequence "65 AE" is trapped as invalid opcode on the 80186 and 80286, it is executed as "compare a single byte at [FS:SI] to the single byte at [ES:DI], then increment both SI and DI (FS:; CMPSB)" on the 80386 (and I am confident EMU386 emulates this instruction perfectly), but it is executed as "compare bytes at [DS:SI] to bytes at [ES:DI], increment SI and DI after each byte, decrement CX after each byte, until a byte at DS:SI is found to be bigger than the corresponding byte at ES:DI or CX reached zero (REPNC CMPSB)" by all NEC V-series processors. It does not generate an INT6 on V40 or V50 processors, so EMU386 doesn't get a chance to emulate the 80386 with the same encoding.

This means an 386 emulator based on trapping invalid instructions is not only impossible on the V20/V30 (because they don't trap invalid instructions), but also on the V40/V50, because it misinterprets some 386 instructions as NEC instructions.

Thanks for the detailed input!

Ok, in short: additional patching for EMU386S.EXE is pointless. Also there is no possibility for proper 386 emulator of this type to be written for NEC V30/20 CPUs... At least I can try to skip all the CPU checks and force the Emu386 to run in DOSBox-X 186 emulated CPU just for fun and to test if there's a reason in string "PC/AT with 80186/80286 processor required" 😀

You are interpreting things the wrong way. That was not explicitly what I told you.

I will make it far simpler:

Another solution is to just patch with 90 (NOP instruction) all loc_392 and loc_393. And then in the last three NOP's of loc_393 that you just patched, replace them with BA 2A F5.

That is it, all the cpu detection routine gets overwritten with NOPs and we just claim we have a 386, no matter the cpu type.

I have already written a proper cpu detection mechanism for those processors in the past (CPUDET.COM which is available in MiNiDOS). It is nothing out of the ordinary and small enough it could fit. But I see no reason to take the time to implement this since you already have the main issue solved right above.

In any case, the issue is that it "may" not work as I said in a previous post.

@mkarcher Thank you very much for your help, kudos to you.

Also there is no possibility for proper 386 emulator of this type to be written for NEC V30/20 CPUs

Um,I wouldn't say this. It depends. It's certainly possible to emulate a different CPU on 8086/V30.
There are many CP/M emulators that emulate full Z80 instructions set on plain 8086, for example.

Last but not least, there's QB8086, an IBM PC emulator that runs on DOS-based 8086/80286 PCs with VGA (my video series).

That would be needed is an emulated CPU core that basically emulates 8086 instructions one by one using native 8086 instructions,
but also goes extra steps at emulating 80386 instructions.
80286 instructions need to be handled, too, but the code-path might be different among 8086/8086 and the 8086-2 ISA group (NECs).

Don't assume wonders, though. Performance will be noticeable slower than using Emu386.
The emulator could perhaps be implemented like an CP/M emulator, maybe. Or like MS-DOS Player.
You'd run your 386 program as a parameter (386em appname.exe).

But that being said I think I'm just a layman here.
There are other things to consider. The i/o and the memory must be handled by the emulator somehow.
It's essentially like building an 80386 "VM" that has an emulation core for the processor, I'd imagine.

igully wrote on Yesterday, 18:41:

You are interpreting things the wrong way. That was not explicitly what I told you. […]
Show full quote

You are interpreting things the wrong way. That was not explicitly what I told you.

I will make it far simpler:

Another solution is to just patch with 90 (NOP instruction) all loc_392 and loc_393. And then in the last two NOP's of loc_393 that you just patched, replace them with 2A F5.

That is it, all the cpu detection routine gets overwritten with NOPs and we just claim we have a 386, no matter the cpu type.

Yep, I agree. And this can give me a chance to test if the thing will work on DOSBox-X emulated 186 CPU. But using too much "nop" is for l4m3r5 😜 I can make it skip all the CPU checks by changing "jae loc_392" to "jae loc_394" and this will more hacky way, but still it totally breaks all the CPU type checking functionality. At least I'll do it for the test if it will really work on software emulated 186.

igully wrote on Yesterday, 18:41:

I have already written a proper cpu detection mechanism for those processors in the past (CPUDET.COM which is available in MiNiDOS). It is nothing out of the ordinary and small enough it could fit. But I see no reason to take the time to implement this since you already have the main issue solved right above.

The main issue is that it "may" not work as I said.

This "sounds" familiar... So, you're Ignacio - the author of CPUDET DOS tool. I searched for some site with your DOS tools and found none by the name from CPUID's "help screen". Do you have any?

As for the "main issue", I already solved by myself in different way compared to TheElf's solution, but some freaks are lurking here in the shadows and I'm sure they'll be triggered if I publish the patch here even if it's for sharewre/free version software 😉