raddad772 / jsmoo Goto Github PK

I hope this won't be another false positive.
Some 0xCB prefixed opcodes show 11 cycles instead of 12 in the tests.
For example, 0xCB 0x46.
Thanks

as in BC/B == 0

APU not emulated yet, this is a near-term todo

Hi.

Thanks for your awesome test files... I've been using them to implement a Z80 emulator.

My emulator passes everything I've implemented, but I can't get it to pass the test "FD 18".

Do you know what this is testing? I can't find that instruction combination documented anywhere...

Also, I seem to have a few unimplemented instructions that you test for. Are you privvy to some secret documentation? :D

Thanks,

Steve.

Hey,
for better reach of the community, I would like to suggest to add the following topic to the repository: motorola-68000

How to do this

DSP not emulated yet, this is a TODO

Flags seems wrong for opcode EDB3 (OTIR).
For example, the documentation says that the C flag (the lower bit of f) is unaffected by this instruction, but in the test cases C is changed.

Hello,
opcode ED 5F should be simply a copy of register R in A, but from the tests, R and A are incremented...
Thanks

In chapter 4.3 "I/O Block Instructions" "The Documented Z80 Undocumented" states that:

for IND/INDR: 
        HF and CF Both set if ((HL) + ((C - 1) & 255) > 255)
for INI/INIR:
        HF and CF Both set if ((HL) + ((C + 1) & 255) > 255)

The way you do flag C for IND, matches the book:

this.regs.F.C = ((((this.regs.C - 1) & 0xFF) + data) & 0x100) >>> 8;

but the way you do it for INI does not:

this.regs.F.C = +(((this.regs.C + 1) + data) > 0xFF);

Is this a bug, or was there a reason to implement it this way?
Thanks!

SPC700 core does all work immediately and then just waits the correct number of cycles. I did this before I understood how fast the approach I took with the 65816 is (it takes up less than 15% of execution time). I'll be refactoring it to use the same bus-cycle-accurate techniques as other cores.

The opcode 0xdb is "in a,(n)", but the final value of "a" depends on the emulated system.
So this type of test is unpassable.

I plan to improve this after I get the core going 100%, as the code generation for this one is a bit messier than the others

Hi,

If I don't care about cycle emulation, how can I run these tests reliably?

I mean, counting distinct addresses within the cycles fails on the first test.

I don't want to check for PC hitting the final PC value since there may be loops.

Byte set in RAM don't seem contiguous, so I can't really just count them...

Any pointers greatly appreciated.

Thanks,

Steve.

Running the FD 18 tests, it looks like the test is expecting the carry flag to be set, but it isn't.

Here is the output from my test runner if it helps...

  Test: FD 18 0000            RAM:   3B    Operations:  65536    Result: [ FAIL ]

        Initial       Expected          Actual
    PC: 0xBBBA        PC: 0xBBBB        0xBBBA
    SP: 0xF94E        SP: 0xF94E        0xF94E
    A : 0x39          A : 0x39          0x39
    B : 0x41          B : 0x41          0x41
    C : 0x92          C : 0x92          0x92
    D : 0x4A          D : 0x4A          0x4A
    E : 0xD1          E : 0xD1          0xD1
    H : 0x4F          H : 0x4F          0x4F
    L : 0x28          L : 0x28          0x28
    I : 0xFD          I : 0xFD          0xFD
    R : 0x5D          R : 0x5F          0x5C
    IX: 0x4354        IX: 0x4354        0x4354
    IY: 0xFFB8        IY: 0xFFB8        0xFFB8

    F :    XHX        F :    XHX           XHX

    RAM differences:  NONE

    SOPSET 0xFD

    JR C, e             PC: 0xBBBB    SP: 0xF94E    Flags:    XHX
                        PC: 0xBBBD    SP: 0xF94E    Flags:    XHX

    NOP                 PC: 0xBBBD    SP: 0xF94E    Flags:    XHX
                        PC: 0xBBBE    SP: 0xF94E    Flags:    XHX

Thanks for the excellent test suite though!

Cheers,

Steve.

The generated SPC700 tests never start with the H-flag set, meaning opcodes that depend on its state are not tested fully for correctness. This affects DAA (0xdf), DAS (0xbe) and CLRV (0xe0). Additionally, other opcodes could clear it accidentally and not be caught by the tests as they are now.

It looks like this is caused by the generator wanting to never start tests with the B-flag set, but masking off the wrong bit in the PSW by mistake. It's probably better to not mask off any bits, as never starting with the B-flag set would mean it doesn't check for opcodes accidentally clearing it.

Easy65816 is a TODO

Thanks for such a detailed set of tests! They're incredibly helpful.

It's quite possible that I've misunderstood, but I think three of the test files have errors:

1. The tests for 0xE9 (JP (HL)) have a RAM entry for the initial program counter (0xE49E / 58526 in the first test case), instead of the HL register (0xBC84 / 48260 in the first test case). This means that the emulator will find an arbitrary value in (HL) and jump to an arbitrary address. This appears to be true for all of the 0xE9 test cases.
2. The tests for 0xFB (EI) expect the EI instruction to ignore IME and set the IE register. My reading of the manual on page 32 suggests that this is incorrect and the instruction should instead ignore IE and set IME. This would be consistent with the corresponding tests for 0xF3 (DI). I was slightly confused by the presence of the IE register in the tests, as the README says that memory is flat and registers are ignored.
3. A much more minor issue is that the final states for the tests for 0xFE (CP d8) appear to be missing a value for the IE register. This caused my tests to fail as they were reusing the value from previous tests. I fixed this by more robustly resetting the test state, but it would be nice not to need to. If I've understood correctly, the IE register could be removed from all tests, which would also work.

Thanks again for all your work. Apologies if I've misunderstood anything.

For Z80, the 100/101 json tests, and their DD/FD prefixed counterparts, don't test all the cycles that your implementation has. The tests assume they operate like nop

they're weird ones, but I think it'd be ok for other users to special case it so that the appropriate irq/reset event is triggered at the right time based on the file

Almost all the HALT tests seem to expect PC incremented by one, while PC should remain unchanged, for the definition of HALT.

Thomas Harte may provide some, or someone else, or I may translate the Ares Z80 into a unit test generator