emu86
emu86 copied to clipboard
mfld-fr
Add opcodes of R8810
I've summarized the missing opcodes based of the NULL handlers found on the op-exec.c file:
- OP_DAA
- OP_DAS
- OP_AAA
- OP_AAS
- OP_SALC
- OP_WAIT
- OP_ESC: This one in particular might be of interest, since we can (and I've already drafted a hack for that) add dummy code that doesn't do anything FPU related, as a normal 80x86 would do when no FPU is present.
I haven't included the ones marked as "hole" since I wasn't sure if these are already handled or not. Please validate if I've missed something or not. Thanks!
- SALC (0xD6) : according to http://ref.x86asm.net/coder32.html, that instruction is out of scope of EMU86, as it is >= 80286 (2+)
- DAA, DAS, AAA & AAS : correct, they are still missing
- WAIT (0x9B) : only needed for FPU
- ESC : what do you mean by 'a normal 8086 would do without a FPU' ?
@mfld-fr : Assuming we don't want to emulate an FPU for the time being, an 80x86 that doesn't have an attached FPU, will only execute nops when an ESC sequence is found. It's assuming that the FPU will do whatever it's needed to execute the FPU instruction which might or not modify the memory.
As far as I could understand yesterday when checking what were these ESC codes, programs usually check for the existence of the FPU by initializing it (fninit) and storing the status word on a memory location (FNSTSW [memory]) that was pre-set with a known value. If the FPU is not present, that memory location would keep its pre-set value, but if the FPU exists, then that memory would get the FPU status word.
Source: https://retrocomputing.stackexchange.com/questions/16529/detecting-the-external-x87-fpu
So you want to execute a NOP when decoding an ESC, to allow any FPU detection code to find out there is actually not FPU, in place of stopping the emulator as today ? That's make sense, but I would add a warning like 'ESC without FPU'.
@mfld-fr : Yes, that's the goal for implementing ESC sequences as of now. I'll create a PR later today with a draft that I have, which at least fools some pre-compiled applications into thinking that there's no FPU.
But from what I read in the 80C186 / 80C188 datasheet, FPU interface is not supported, and the CPU would generate the INT 07h for all the ESC opcodes, whatever the 'trap bit' in the opcode.
Yes, that is correct.
I think this behavior is 80C18x dependent, and not 80x86 related.
So it means we would need an option (in config.mk ?) to tell EMU86 we want to emulate the 8086/8088 behavior or the 80186/80188 one... this option is also needed for issue #4 by the way.
Yes, you're correct. How would you like to proceed? I think having that option in config.mk would make sense. Then, (and even if I don't fully like it), we should be able to add some ifdefs to change the behavior on the op-exec. What do you think?
Yes, let us add an option in config.mk. Because of #4, I am afraid the #ifdef / #endif that you don't like are the simplest way to select the expected behavior, not only in op-exec, but also in op-class, because of some differences in decoding too.
That's perfectly fine, I usually dislike these because it's difficult to read code that's plagued with #ifdef / #else / #endif. But I think it should be fine in this case.
My input to this discussion is that, of course, few #ifdef's or best none, but hopefully the default option is one where users of MSDOS/FreeDOS or associated user programs that use ESC to determine whether FPU is present do not have to research or set a config option to use EMU86. I kind of like the idea of ESC executing NOPs but a warning 'ESC without FPU'.
