MEMPTR tests for emulator authors

edited November 2012 in Emulators
I've recently been completing my MEMPTR implementation and have written a series of tests in this program to verify the MEMPTR docs (which are spot on) , as well as a brief run through several of the DD/FD/CB opcode ranges, and may be of some use for other authors planning to implement it.

The test results in the program are compared against those from an NEC D780C-1 Z80 chip, but Bad Beard has kindly tested several other Z80 clones, confirming the same results.
Post edited by Woody on

Comments

  • edited April 2008
    Nice one :)

    Jon.
  • edited April 2008
    I doubt I'll ever bother to make it work in ZXDS, but nice one anyway.
  • edited October 2012
    I have noticed that this has been updated quite a lot since it was posted originally.

    I was wondering if someone had a chance to run it on a genuine Zilog CPU, to see if it really does the OR of the bits 5+3 after SCF/CCF rather than copy like NEC does?

    Patrik

    P.S. Waiting for no keypress before keypress would help when running this at 1000+% :)
  • edited November 2012
    Patrik Rak wrote: »
    I was wondering if someone had a chance to run it on a genuine Zilog CPU, to see if it really does the OR of the bits 5+3 after SCF/CCF rather than copy like NEC does?

    OK, I decided to test it myself, so I finally got around to plugging in the real 48k Speccy I have around. I had problems setting up the audio for loading, so I first tried the first type-in from these scftests. It clearly shows that the 5+3 flags after POP AF ; SCF and POP AF ; CCF are set to OR of F and A.

    Later on, though, I managed to set up the audio and loaded the Woody's test and surprisingly everything passed. As Woody mentioned in one discussion, he is using SCF+CCF and CCF+SCF to make it work the way it does, so I modified my test and indeed, after these two operations the 5+3 F result was not OR of F and A anymore, but a move from A instead.

    I than verified the same thing for all 256 values of F and all 4 values of 5+3 bits of A. The result after the single operation was OR, while after sequence of both it was move. So it clearly doesn't depend on any bit of F register, which is quite annoying. BTW, the results were absolutely stable, too, nothing random like Woody has experienced.

    I then tried to put few other instructions between POP AF and the SCF/CCF, to see what the outcome is. In case the instruction didn't modify the flags, it was still OR. And if it did modify the flags, I realized I couldn't tell which it was as I have only used instructions which set the flags based on A. I will try to come up with a more thorough test tomorrow.

    Regarding the CPU, I hadn't opened this Spectrum yet before but I strongly believe it is a genuine Zilog CPU. I'll verify that later as well.

    Patrik
  • edited November 2012
    OK, I did few more tests. First I tried 2xSCF and 2xCCF, both result in move. So does 3xSCF and 3xCCF. Since then, I started putting various instructions between two SCF instructions. Here is what I tried:
    PUSH AF+POP AF
    PUSH BC+POP BC
    LD BC,x
    LD BC,x+PUSH BC+POP BC
    EI
    2xEX (SP),HL
    LD B,B
    JR +0
    2xEX AF,AF'
    INC BC
    NOP
    
    In each case the last SCF did OR operation.

    Then I started putting in the operations which affect the flags. I played with INC B and DEC B, for various values of B, so I was able to prove that the last SFC does move operation, not OR. However, as soon as I put NOP after the INC/DEC B in question, the operation changed to OR again.

    Therefore, my conclusion so far is that when an operation affects the flags, the subsequent SCF or CCF operation performs move operation (i.e., the 5+3 flags become copied from A). When an operation doesn't affect the flags, the subsequent SCF or CCF operation performs OR operation (i.e., the 5+3 flags are OR of their previous value and A).

    On a hardware level, I believe that there might be additional register, let's call it Q, which keeps the copy of the flags register (or at least the bits in question) when the operation sets it and which is reset when it does not. The SCF/CCF then merely sets 5+3 flags to ((Q^F)|A). Expanding on this idea should lead to fairly simple implementation in any emulation core as well. OTOH, if this is true, it may turn out that there are more quirks to be found after some instructions...

    Honestly, I am not sure whether these findings will please the emulation authors or not. Obviously it will require adding at least one additional bit to SZX specs if this additional internal CPU state is to be preserved correctly.

    In either case it would be great if someone with more spare time on his hands could write a test to prove this thoroughly. I know that it will be likely unreliable for NEC CPUs, but it should work fine on Zilog ones. Woody? Philip? Jon? Any volunteers?

    Patrik
  • edited November 2012
    Just in case someone stumbles upon this in the future, the discussion goes on in this other thread.

    Patrik
Sign In or Register to comment.