Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
06797 Core Minor Always Dec 24, 2017, 07:26 Dec 27, 2017, 09:19
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) Dec 24, 2017, 07:28 Uploaded by drencorxeen
? file icon 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]
Relationships
has duplicate 06798Closed m6809 incorrectly handling opcode 0x104F 
Notes
3
User avatar
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
User avatar
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
User avatar
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;