Re: Likely opcode execution bug

Hi,

22.08.2021 23:36, I wrote:
> I just thought it might have to do with the fact that the code is being
> executed in F000:xxxx area, and the above "mov" instruction also
> operates on address from that range. Of course this is set up as
> writable shadow ROM memory, otherwise the code in question would not
> work at all. But still maybe some underlying implementation of memory
> operation is unhappy about such setup and behaves incorrectly.
>
> Here is a memory fragment showing the appearance of 1 normal and
> following 3 additional bogus copies of this dword, with "dots"
> representing unchanged bytes:
>
> F90B0: .. .. .. .. .. .. .. .. .. 41 D0 04 01 .. 41 D0
> F90C0: 04 01 .. 41 D0 04 01 .. 41 D0 04 01 .. .. .. ..

I've been able to prepare a tiny reproducable example.

Create a dummy 128k BIOS image e.g. like:
dd if=/dev/zero of=test.rom bs=131072 count=1
then overwrite last 64 bytes with the following:

BE D6 FF 66 2E C7 44 03 41 D0 04 01 90 90 EB F0
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
EA C0 FF 00 F0 00 00 00 00 00 00 00 00 00 00 00

This file can then be loaded and executed as main BIOS image.
The disassembly of first line is:
mov si, ffd6
mov dword ptr cs:[si], 0x0104d041

Now stepping through this "ROM" in debugger (with writable shadow memory 
of course) results in the following contents:

0FFFC0: BE D6 FF 66 2E C7 44 03 41 D0 04 01 90 90 EB F0
0FFFD0: 00 00 00 00 00 00 00 00 00 41 D0 04 01 00 41 D0
0FFFE0: 04 01 00 41 D0 04 01 00 41 D0 04 01 00 00 00 00
0FFFF0: EA C0 FF 00 F0 00 00 00 00 00 00 00 00 00 00 00

One can obviously see 3 additional bogus copies of 0104d041 appeared 
here. The effect apparently does not happen if the same example is run 
below 640k boundary, so this seems related to rom memory handling.


Thank you,

Regards,
Nikolai