Two instances of setCCflag in instructions.c that have a parameter missing. setCCflag(CC_N);
Probably intended to be setCCflag(1, CC_N);

Steps to reproduce:

Assemble and run the following code:

LDA #$91
ADD #$91
DAA

What happened?

Carry was reset.

When similar code was used for multi-byte decimal addition, it yielded incorrect results.

What was expected?

Carry should be set. DAA keeps the carry flag set if it was set beforehand, see the mc6809 emulator sources for comparison: https://github.com/spc476/mc6809/blob/master/mc6809.c#L420 or the official Programming Manual: https://archive.org/details/bitsavers_motorola68_13419254/page/n83/mode/2up

C – Set if a carry is generated or if the carry bit was set before the operation; cleared otherwise.

After some research, I noticed that this is a common bug in many 6809 emulators.

In indirect.c, test "Doffset2", could you confirm that the expected value in X after execution is correct? Thanks.

--------------------------------------------------- Doffset2 CC=0x28 X=0EFA Y=0EF8 A=FF B=82 -> X=8E7A Z=0
PC=0400 A=ff B=82 X=0efa Y=0ef8 S=03fe U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 ENTRYPT PSHS U,Y,X,DP,B,A,CC ; 0400: 34 7F
PC=0402 A=ff B=82 X=0efa Y=0ef8 S=03f4 U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 STS $046E ; 0402: 10 FF 04 6E
PC=0406 A=ff B=82 X=0efa Y=0ef8 S=03f4 U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 LDS #$0464 ; 0406: 10 CE 04 64
PC=040A A=ff B=82 X=0efa Y=0ef8 S=0464 U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 PULS CC,A,B,DP,X,Y,U ; 040A: 35 7F
PC=040C A=ff B=82 X=0efa Y=0ef8 S=046e U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 JSR Doffset2 ; 040C: BD 00 00
PC=0000 A=ff B=82 X=0efa Y=0ef8 S=046c U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 Doffset2 LEAX D,Y ; 0000: 30 AB
PC=0002 A=ff B=82 X=0e7a Y=0ef8 S=046c U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 RTS ; 0002: 39
PC=040F A=ff B=82 X=0e7a Y=0ef8 S=046e U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 L040F PSHS U,Y,X,DP,B,A,CC ; 040F: 34 7F
PC=0411 A=ff B=82 X=0e7a Y=0ef8 S=0464 U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 LDS $046E ; 0411: 10 FE 04 6E
PC=0415 A=ff B=82 X=0e7a Y=0ef8 S=03f4 U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 PULS CC,A,B,DP,X,Y,U ; 0415: 35 7F
PC=0417 A=ff B=82 X=0efa Y=0ef8 S=03fe U=0000 CC=28 DP=02 E0F0H1I0C0Z0V0N1 RTS ; 0417: 39
Doffset2:X expected 8e7a - actual 0e7a

The cpu tests are currently structured for executing on a 6809 itself - but that is the only method of execution, if you want to test under emulation, you have to emulate a system that supports these C programs with a runtime library etc and run the entire program as if it were running on a 6809 with console output. However what is often wanted it to test a bare emulator independent of target architecture (or the emulator is for an embedded system with no text I/O, such as the Vectrex). The code as it stands is not capable of doing this, for several reasons. For example there are several places where the byte order within a word assumes IBM/Motorola ordering, so the current C code could not run on systems with DEC/Intel ordering.

I've started a restructuring of the code where an emulator running on a host system can execute 6809 code that is stored in array memory[] which is the common interface between the host and the virtual machine - no other variables can communicate between the two systems. At the moment it supports a binary translation rather than a true emulation, but the major changes needed are the same for both. The program runs primarily on the host and it calls the interpreter to execute only the code fragments in the memory[] array.

Handling this with a static binary translator is actually a bit trickier than just an emulator would have been as the tests have to generate C code, compile it, and link it in and execute it. To avoid OS-specific hassles with dynamic loading, this has turned the process into a 2-pass compilation, which is easiest to handle by just running the code and typing make twice.

So this isn't really ready for release or a fork but I thought you might be interested in seeing the direction I'm taking it and and may have some advice or requests.

gtoal.com/SBTPROJECT/6809sbt/sorenroug-cpu-tests/

regards,

Graham

Hi @sorenroug

Excellent work - especially the cpu tests is something I was looking for! I'll try to adapt them to run in my js 6809 emu.

anyway i tried to install you project on OSX using mvn v3.3.3 - it failed with:

[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'parent.relativePath' of POM roug.org.osnine:osnine-gimix:1.0-SNAPSHOT (/_code/github/osnine-java/emulations/gimix/pom.xml) points at roug.org.osnine:emulations instead of roug.org.osnine:osnine, please verify your project structure @ line 6, column 13
[FATAL] Non-resolvable parent POM for roug.org.osnine:osnine-gimix:1.0-SNAPSHOT: Could not find artifact roug.org.osnine:osnine:pom:1.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 6, column 13
 @
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project roug.org.osnine:osnine-gimix:1.0-SNAPSHOT (/_code/github/osnine-java/emulations/gimix/pom.xml) has 1 error
[ERROR]     Non-resolvable parent POM for roug.org.osnine:osnine-gimix:1.0-SNAPSHOT: Could not find artifact roug.org.osnine:osnine:pom:1.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 6, column 13 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

invalid mvn version?