06797: MC6809 incorrectly handling opcode 0x104F

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
06797	Core	Minor	Always	Dec 24, 2017, 07:26	Apr 8, 2023, 22:19

Tester	drencorxeen	View Status	Public	Platform	MAME (Official Binary)
Assigned To	tlindner	Resolution	Fixed	OS
Status [?]	Resolved			Driver	trs/coco3.cpp
Version	0.192	Fixed in Version	0.254	Build	64-bit
		Fixed in Git Commit	5dc861b	Github Pull Request #	#11050

Summary	06797: MC6809 incorrectly handling opcode 0x104F
Description	On a real m6809 CPU if you run a opcode of 0x104F the real 6809 will ignore the 0x10 opcode part of the instruction and will process the opcode of 0x4F which on a m6809 is a CLRA. Please test on coco3, coco1, coco2.
Steps To Reproduce	Created a test assembly language program to load register D with $FFFF, then issue a 6309 instruction CLRD, then after that writing register A and register B to specific memory locations and using basic to peek and print the values should yield a 0 for A and 255 for B, but the m6809 core in MAME ignores both bytes of the CLRD where it should have only ignored the 0x10. I am including a DSK image for testing. Steps once disk image is mounted in drive 0: LOAD"6309.BAS" RUN On real CoCo 1, 2, 3 with a real m6809 in it the outputs as follows: 0 255 On emulator outputs: 255 255
Additional Information	So the 6309 instruction CLRD (0x104F) the (0x10) is ignored on a real m6809 CPU and thus it still processes the (0x4F) part of the instruction and does a CLRA. I have tested this on a system that does in fact have a real m6809 on it and thus I know in this case how the emulation for the m6809 is not handling this situation correctly.
Github Commit

Flags
Regression Version
Affected Sets / Systems

Attached Files	6309.zip (695 bytes) Dec 24, 2017, 07:28 Uploaded by drencorxeen
Attached Files	m6809_mame.diff (508 bytes) Dec 24, 2017, 18:58 Uploaded by drencorxeen diff file to fix the 0x104F opcode from being eaten and not processed. [Show Content]

No.14556 drencorxeen Tester Dec 24, 2017, 08:55	Here is the assembly file used on my test: ORG $7000 BEGIN JMP START FDB DONE-BEGIN BYT1 RMB 1 BYT2 RMB 1 START EQU * LDD #$FFFF CLRD STA BYT1 STB BYT2 RTS DONE EQU * END BEGIN
No.14557 drencorxeen Tester Dec 24, 2017, 08:56	Here is the basic program that loads the binary off of the disk image that executes the program and then displays the memory locations from the binary: 10 CLEAR 200,&H7000 20 CLS 30 LOADM"6309.BIN" 40 EXEC &H7000 50 PRINT PEEK(&H7005) 60 PRINT PEEK(&H7006) 70 END
No.14558 drencorxeen Tester Dec 24, 2017, 19:00	Ok so I created a quick patch for m6809.ops file to look for this condition and do what a real m6809 would do in this case. Here is the diff file in both file format and text so could be easily read here. ------------------------------------------- diff --git a/src/devices/cpu/m6809/m6809.ops b/src/devices/cpu/m6809/m6809.ops index 125be18..e65f2dc 100644 --- a/src/devices/cpu/m6809/m6809.ops +++ b/src/devices/cpu/m6809/m6809.ops @@ -293,6 +293,8 @@ DISPATCH10: case 0x3F: %SWI2; return; + case 0x4F: set_a(); %CLR8; return; + case 0x83: set_regop16(m_q.p.d); set_imm(); %CMP16; return; case 0x8C: set_regop16(m_y); set_imm(); %CMP16; return; case 0x8E: set_regop16(m_y); set_imm(); %LD16; return;
No.18721 tlindner Developer Apr 19, 2021, 20:54	Have you experimented with other page 2 and 3 opcodes that are undefined? Do they all revert to their page 1 behavior?
No.20451 tlindner Developer Aug 13, 2022, 15:57	This bug's files should be changed to the 6809 CPU core. A detailed study of the undefined / undocumented behavior has been published on the 6809: https://github.com/hoglet67/6809Decoder/wiki/Undocumented-6809-Behaviours
No.21290 tlindner Developer Apr 7, 2023, 17:04	This has been fixed with pull request: https://github.com/mamedev/mame/pull/11050