This test in tests/asm.fs appears to be testing the simulator rather than testing Tali, and it fails under py65mon:
\ Testing undocumented nops; all three dec.a should be skipped
: nops [ 3 lda.# nop 22 c, dec.a 5c c, dec.a dec.a push-a ] ;
T{ nops -> 3 }T
The py65mon folks may be aware of this, as they were working on passing the Klaus Dormann tests and mentioned the unused opcodes did not pass - I didn't see any mention of being concerned with that (the folks working on it were more concerned with getting ADC to work correctly in BCD mode, which I believe has already been fixed in 2019), so I don't believe any fixes are imminent unless we want to put in a new issue.
Because Tali doesn't generate these opcodes and doesn't run them either, I don't think we need to test them here. Tali should run on all platforms that implement all of the used opcodes, including simulators and FPGA versions that may have unknown behavior for the unimplemented opcodes that differs from a real 65C02.
The c65 tests also fail, not with a test suite failure, but with "Undefined word or invalid number" failure (which then results in "Interpreting a compile-only words" failures. Here's the summary from running make tests:
Summary for: core_a core_b core_c string double facility ed asm tali tools block search user cycles
Tali Forth 2 ran all tests requested
T{ nops -> 3 }T INCORRECT RESULT: T{ nops -> 3 }T ACTUAL RESULT: { 2 } ok
block-c65-init if >block-c65-init< Undefined word or invalid number
." testing c65 block read/write" Interpreting a compile-only word
else Interpreting a compile-only word
." no c65 block device" Interpreting a compile-only word
then Interpreting a compile-only word
; Interpreting a compile-only word
I think the solution here is to make sure the block-c65-init word exists (in block.fs) before running the test for that near the bottom of block.fs. The sequence s" block-c65-init" find-name will return the XT or zero depending on if the word exists or not.
This test in tests/asm.fs appears to be testing the simulator rather than testing Tali, and it fails under py65mon:
The py65mon folks may be aware of this, as they were working on passing the Klaus Dormann tests and mentioned the unused opcodes did not pass - I didn't see any mention of being concerned with that (the folks working on it were more concerned with getting ADC to work correctly in BCD mode, which I believe has already been fixed in 2019), so I don't believe any fixes are imminent unless we want to put in a new issue.
Because Tali doesn't generate these opcodes and doesn't run them either, I don't think we need to test them here. Tali should run on all platforms that implement all of the used opcodes, including simulators and FPGA versions that may have unknown behavior for the unimplemented opcodes that differs from a real 65C02.
The c65 tests also fail, not with a test suite failure, but with "Undefined word or invalid number" failure (which then results in "Interpreting a compile-only words" failures. Here's the summary from running
make tests
:I think the solution here is to make sure the block-c65-init word exists (in block.fs) before running the test for that near the bottom of block.fs. The sequence
s" block-c65-init" find-name
will return the XT or zero depending on if the word exists or not.