| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 06798 | Core | Critical (emulation) | Always | Dec 24, 2017, 07:27 | Dec 24, 2017, 11:38 |
| Tester | drencorxeen | View Status | Public | Platform | MAME (Official Binary) |
| Assigned To | Resolution | Duplicate | OS | Windows 10 (64-bit) | |
| Status [?] | Closed | Driver | |||
| Version | 0.192 | Fixed in Version | Build | 64-bit | |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary |
 06798: m6809 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:27 Uploaded by drencorxeen | ||||