I think pure 8086 and pure 80286 emulation on DOSBox. For this, cputype option has "086" and "286" settings in DOSBox options.
How would this be useful?
World's foremost 486 enjoyer.
Indeed. If you are seeking "pure", accurate emulation, you should not be using DOSBox.
I cannot recall anyone ever posting about trying to run a program in DOSBox that wouldn't work because it was expecting a 8086 or 80286 for some reason.
I can. A core emulating the particularities of the 8088 would in fact improve its compatibility with certain 1980s games such as early versions of MS Flight Simulator, The Seven Cities of Gold, Lode Runner, or President's Choice. These games do not run unmodified under vanilla DOSBox, because they exploit some of the idiosyncracies of the 8086/8088 such as the different return address of the Divide Error exception, or the POP CS and MOV CS, xxx instructions. (Well, they also don't run unmodified because the originals use on-disk copy protection.)
If I ever find the time to improve my Floppy Controller and copy-protected floppy diskette image emulation enough to release it as a source code patch, it will also include an 8088 cputype, because it is needed for some disk copy protection schemes.
wrote:I can. A core emulating the particularities of the 8088 would in fact improve its compatibility with certain 1980s games such as early versions of MS Flight Simulator, The Seven Cities of Gold, Lode Runner, or President's Choice. These games do not run unmodified under vanilla DOSBox, because they exploit some of the idiosyncracies of the 8086/8088 such as the different return address of the Divide Error exception, or the POP CS and MOV CS, xxx instructions. (Well, they also don't run unmodified because the originals use on-disk copy protection.)
Does that mean these games would only run on an 8086/8088 and would not run at all on a 286? (I presume even a 386 would already be too fast for them to run playably.)
Also, these's fixed CPU clock.
wrote:Does that mean these games would only run on an 8086/8088 and would not run at all on a 286?
That's right.
In Seven Cities of Gold, only the World Maker is affected (to my knowledge), because it frequently causes divide errors (either from dividing by zero or having a division result that is too large for the target register), and the 8088 returns from Int00 to the instruction following the offending DIV instruction, whereas 286 and later return the DIV instruction itself. This is usually the biggest problem, because the 8088 thus does not force the programmer to actually deal with the problem, and so some early games just didn't bother.
Lode Runner freezes before showing the playfield, because it uses the POP CS instruction. Because POP CS is a one-byte instruction (0Fh) on the 8088, whereas 286+ interpret 0F as the first byte of a multi-byte instruction that in Lode Runner's case would be an illegal instruction, it causes an Illegal Instruction exception (Int 06), and as with Int00, Int06 returns to the offending instruction itself on 286+, thus code execution gets stuck. Lode Runner is therefore completely unplayable unmodified on 286 and above even with slowdown utilities.
Because the instruction is completely ineffectual in Lode Runner's case, as the popped CS is always identical to the current CS --- the programmer was probably just trying to PUSH and POP the entire CPU state in that particular code section --- replacing the POP CS with POP AX would be entirely sufficient and trivial, if it were not for the fact that the game regularly hashes its own code segment content to check for attempts at cracking, hacking or debugging with Int03 breakpoints.
Huh. Well, that is educational. Thank you.
wrote:Also, these's fixed CPU clock.
People have been asking about that for many years now. While I imagine improved instruction handling for old CPUs could very well happen, "fixed CPU clock" is not happening in DOSBox and probably will never happen in DOSBox, as DOSBox just isn't written that way. You certainly don't get any such thing with settings like "386" and "386_slow" in the current versions.
Sample threads:
How to determine max CPU cycles DOSBox can emulate from real CPU clock rate
Determining CPU Cycles?
Discussion of DosBox processor emulation
"386_slow"'s clock is equal 8086's clock or 80286's clock?
You can reduce the number DOSBox cycles to slow execution down to approximately the speed you would expect for one of those processors, but you cannot precisely equate it to any particular clock speed, and if that is what you need, you should not be using DOSBox.
Also, "486_slow" and "pentium_slow" settings in DOSBox options.
What about them? I can't recall exactly what they do – something about specific processor instructions, I think – but they are very rarely used and certainly don't have much to do with accurate clock speeds.
