I used this years ago to run Creative Soundblaster Drivers using some 386 Instruction (CTCM etc)

analog_programmer wrote on Yesterday, 07:59:

I'm not sure that this confirms 100% the Emu386 can turn a 80186 into a real mode 80386, but managed to run "Dos-J Plus" driver […]
Show full quote

I'm not sure that this confirms 100% the Emu386 can turn a 80186 into a real mode 80386, but managed to run "Dos-J Plus" driver (requires 386 CPU) from this Jo22's post in DOSXbox-X with emulated 80186 + loaded Emu386 (well, the J-thing complains for no XMS memory, but at least it doesn't hang as it does on 286 or 186 without 386 emulation):

The attachment Dos-J Plus on 80186+Emu386.jpg is no longer available

I think this gives some hope, that EMU386S.EXE will be usable on a real 186 hardware. I'm still very disappointed from NEC's V30/20 "gems" with their missing INT6.

I don't know if it is worth to make a patch for proper 186+286 CPUs detection in Emu386 as I don't know someone who has XT-class machine with the weird 80186 CPU. Maybe I'll try something just for fun in DOSBox-X emulator.

P.S. igully's CPUDET.EXE reports it was running on 80188 while the emulation is for 80186 - maybe some minor bug. Jan's CHKCPU.EXE gives proper report for 80186.

The problem is that you are running a CPU emulator that is not accurate enough, so the CPU input prefetch queue which is used to measure the bus width gives inaccurate results. This is self-modifying code and the way DOSBox was designed, was to be fast, but not accurate. On a real machine or a more precise emulator it should work.

I suggest that for stability/reliability tests you never use inaccurate emulators or dynamic recompilation mode on any of them. Don't get me wrong, this is a trade-off developers make for a reason: precision vs emulation speed, which makes sense in "many" circumstances, but certainly not all.

igully wrote on Yesterday, 16:26:

The problem is that you are running a CPU emulator that is not accurate enough, so the CPU input prefetch queue which is used to measure the bus width gives inaccurate results. This is self-modifying code and the way DOSBox was designed, was to be fast, but not accurate. On a real machine or a more precise emulator it should work.

I suggest that for stability/reliability tests you never use inaccurate emulators or dynamic recompilation mode on any of them. Don't get me wrong, this is a trade-off developers make for a reason: precision vs emulation speed, which makes sense in "many" circumstances, but certainly not all.

I fully agree with this. But my oldest working PC-system is with 80286 CPU and currently it's fully disassembled. And I don't know someone with 80186 system. So, the only option for testing is DOSBox-X.

I'll suppose, that Emu386 can be used on 80186 system. I wish I could make a patch for missing 80186 CPU detection, but unfortunately I barely understand what's happening in this piece of code:

1loc_392:			;  xref 26C6 <- start of function to check for 80286 processor only
2push	sp			; ???
3pop	ax				; ???
4cmp	sp,ax			; ???
5je	loc_393			; Jump if equal <- processor is 80286, jump to loc_393
6mov	dx,2AC9h		; <- (2AC9='PC/AT with 80186/80286 processor required')
7jmp	short loc_390	; (269C) <- jump to loc_390 to print 'ERROR: PC/AT with 80186/80286 processor required...' and exit
8
9loc_393:			;  xref 26D1 <- start of function to check if processor is 386 or newer
10pushf				; ???
11or	bx,0F000h		; ???
12push	bx			; ???
13popf				; ???
14pushf				; ???
15pop	ax				; ???
16popf				; ???
17and	ax,0F000h		; ???
18jz	loc_394			; Jump if zero <- processor is not 386 or newer, jump to loc_394
19mov	dx,2AF5h		; <- (2AF5='Processor is 386 or above')
20jmp	short loc_390	; (269C) <- jump to loc_390 to print 'ERROR: Processor is 386 or above...' and exit
21
22loc_394:			;  xref 26E5

Here are the missing comments:

1loc_392:			;  xref 26C6 <- start of function to check for 80286 processor only
2push	sp			; push the value of the current stack pointer to the stack. This modifies the current stack pointer
3pop	ax				; pop the values pushed to the stack. This will return the stack pointer to the original value
4cmp	sp,ax			; compare whether the value pushed by "push sp" is the "old" or the "new" value. The 8086 and 80186 push
5					; the value after modification, while all newer processors push the value before modification.
6je	loc_393			; Jump if equal <- processor is 80286, jump to loc_393
7mov	dx,2AC9h		; <- (2AC9='PC/AT with 80186/80286 processor required')
8jmp	short loc_390	; (269C) <- jump to loc_390 to print 'ERROR: PC/AT with 80186/80286 processor required...' and exit
9
10loc_393:			;  xref 26D1 <- start of function to check if processor is 386 or newer
11pushf				; push the flags to the stack (save them for later recovery)
12or	bx,0F000h		; ensure the top 4 bits of BX are set
13push	bx			; push the value of BX to the stack
14popf				; pop the value from the stack into the flags register (into all bits that are actually writeable)
15pushf				; push the contents of the current flag register back to the stack
16pop	ax				; pop the value of the current flags register into AX
17popf				; restore the flags
18and	ax,0F000h		; isolate the top 4 bits of AX. On a 286 processor in real mode, these bits are
19					; fixed at zero.
20jz	loc_394			; Jump if zero <- processor is not 386 or newer, jump to loc_394
21mov	dx,2AF5h		; <- (2AF5='Processor is 386 or above')
22jmp	short loc_390	; (269C) <- jump to loc_390 to print 'ERROR: Processor is 386 or above...' and exit
23
24loc_394:			;  xref 26E5

This code is bad, because the test used to detect whether the CPU is at least 80186 actually tests for 80286. The "push sp" behaviour changed with the 286, not with the 186, as described in https://wiki.osdev.org/User:ChosenOreo/CPU_De … r_Microcode_Bug .

A suitable test for 80186 would be shift count limiting: Try

1loc_392:
2mov	cl,021h
3shl	cl, cl
4jne	loc_393

The idea is that an 8086 will shift CL left by 21 hex (33 decimal) bits, which will clear it, so the zero flags get set. On the 80186 and later, only the low 5 bits of CL are used for the shift count, so CL is shifted by a single bit, making it 42h / 66 decimal. Obviously, the zero flag will not be set in this case.