03481: all PC-based sets: dasm disassembly is incorrect for PC BIOS

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03481	Debugger	Major	Always	Oct 22, 2009, 18:20	Oct 24, 2009, 03:12

Tester	Luigi30	View Status	Public	Platform	MAME (Self-compiled)
Assigned To		Resolution	No change required	OS	Windows XP (32-bit)
Status [?]	Closed			Driver
Version	0.134u3	Fixed in Version	0.134u4	Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03481: all PC-based sets: dasm disassembly is incorrect for PC BIOS
Description	The dasm command produces a disassembly of a chunk of memory and puts it in the MAME folder. For PC-based sets a disassembly of the BIOS can be retrieved by running "dasm bios.asm,ffff0000,10000". When examined, the disassembly differs from the memory window. Take pf2012 for example. The instruction at FFFF:FFF0 is EA 5B E0 00 F0. It is shown correctly in the memory window. However, the disassembler's output is offset by one address and is incorrect: FFFFFFEF: 00 EA add dl,ch FFFFFFF1: 5B pop bx FFFFFFF2: E0 00 loopne 0FFFFFFF4h FFFFFFF4: F0 lock It is disassembled correctly if you start disassembling at FFFF:FFF0, so it should recognize the instruction. This could be an indication of it disassembling a previous instruction incorrectly and taking too many or not enough parameters causing the disassembly to shift, but I'm not sure. All 386, 486, and Pentium disassembly is handled by emu/cpu/i386/i386dasm.c.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version
Affected Sets / Systems	all PC-based sets

Attached Files

No.05051 Luigi30 Tester Oct 22, 2009, 18:32	There's the correct description.
No.05052 Haze Senior Tester Oct 22, 2009, 19:13	I'm not sure it can be considered a bug. The alignment gets shifted during disassembly due to multi-byte opcodes etc. Sometimes it simply can't know where an opcode starts / ends unless you tell it. Somewhere in the process of interpreting opcodes and their parameters it becomes misaligned, and stays that way, it has no way of knowing better. I'm sure it affects more than just the x86, but it's hard to consider it a bug because it's just the nature of diassemblers.
No.05054 robiza Developer Oct 24, 2009, 03:12 edited on: Oct 24, 2009, 03:13	not only "nature of disassemblers" but "nature of code execution" jmp FFFFFFEF execute the code in the description jmp FFFFFFF0 execute the other code "the disassembly differs from the memory window" (-> dasm window) it depends; we can select the first value to dasm in the window