Czerno Bill

@Akaseo : sorry for not answering earlier, I was not online during the week end. Also I'm afraid I'm not going to have the time to run the test case which you so kindly took the time to compile, maybe someone else reading this discussion will ? In any case I'm persuaded You yourself are fully qualified to chase and debug whatever mysterious behavior you have uncovered, sort of. Just one last thought : concerning the possible flaw being in Bochs bundeled debugger, it is certainly far from impossible...

GPF really ? Rather Divide-by-zero (quotient. overflow) isn't it ? Still you aren't telling us whether you are 100 % certain that the last inxtruction executed (before the faulting /div/ had been the xor @1064df ! Again, had you been single-stepping the coden or freely running ? Is that a fragment of a programme YOU wrote, or have the source for ? Or is it 3-rd party code which you are "debugging" and/or sying upon ? Or else some random piece of code that happens to be where your Bochs experienced...

Were you single-stepping that code fragment in Bochs, or breaking at 0x1064e1 ? Before starting to speculate any more, can you please check / ensure that the xor instruction was indeed executed : couldn't the stopping point be attained byjmping from somewhere else in your code rather than sequentially from the preceding xor? Apologies if the question seems stupid and/or offending, I'm only trying to help...

Anybody knows if exists some earlier Bochs version - or other freely available programme - simulating a i80286 with PCAT-like hardware ? Wanted accuracy of instruction simulation, similar to Bochs, not necessarily cycle-accurate (but a count of cycles, per Intel's manual, even if approximate, assuming zero-wait-state etc, would be a bonus instead of present Bochs' notion of 1 instruction== 1 cycle). Wanted full emulation of protected as well as RM. Additionnal bonus points for so-called "undocumented"...

Yet another annoying (well, it has me annoyed !) non-conformance in Bochs emulation with respect to real "metal" : the real mode floppy BIOS takes no account of the actual contents of the DPPT in memoy, that could be any garbage and still floppy operations work like magics ! Should I be happy ? Depends upon what one is doing. Of course some ppl might /love/ the magics, but others who expect as good as possible emulation of a real PC-AT compatible system will certainly object !

It will hurt when, rebooting e.g. in a DOS environment, some installable system driver checks an absolute address for the presence or absence of some specific pattern and it could be fooled if the memory was not cleared by the BIOS during init. In order to emulate a PC-compatible system properly, the memory MUST be cleared by BIOS init UNLESS it's a "warm" reboot (instead of reset) AND the appropriate tag (0x1234) is found at absolute address 0x00472 (if memory serves). For practical reasons, you...

It will hurt when, rebooting e.g. in a DOS environment, some installable system driver checks an absolute address for the presence or absence of some specific pattern and it could be fooled if the the memory was not cleared by the BIOS during init. In order to emulate a PC-compatible system properly, the memory MUST be cleared by BIOS init UNLESS it's a "warm" reboot (instead of reset) AND the appropriate tag (0x1234) is found at absolute address 0x00472 (if memory serves). For practical reasons,...

I guess this quirk report concerns the maintainer of Bochs BIOS. On reboot & especially, reset, Please clear the memory of the emulated PC, at least 640k of "conventional" memory. Although it may not be important frequently, yet Bochs's failure to do so may sometimes "hurt" :=)