Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06797 Core Minor Always 27 days ago 24 days ago
Tester drencorxeen View Status Public Platform MAME (Official Binary)
Assigned To Resolution Open OS Windows 10 (64-bit)
Status [?] Acknowledged Driver coco3.cpp
Version 0.192 Fixed in Version Build 64-bit
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.
Flags
Regression Version
Affected Sets / Systems
Attached Files
zip file icon 6309.zip (695 bytes) 27 days ago Uploaded by drencorxeen
? file icon m6809_mame.diff (508 bytes) 27 days ago Uploaded by drencorxeen
diff file to fix the 0x104F opcode from being eaten and not processed.
[Show Content]
Relationships
has duplicate 06798Closed m6809 incorrectly handling opcode 0x104F 
Notes
3
User avatar
No.14556
drencorxeen
Tester
27 days ago
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
User avatar
No.14557
drencorxeen
Tester
27 days ago
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
User avatar
No.14558
drencorxeen
Tester
27 days ago
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;