Some interesting (For some people) facts about ZX81 - Sinclair

This is a discussion on Some interesting (For some people) facts about ZX81 - Sinclair ; Whilst attempting to write my own ZX81 emulator purely as a personal challenge, I have discovered a few interesting things about our beloved little machine. so i had the problem where the image in fast mode is shifted to the ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Some interesting (For some people) facts about ZX81

  1. Some interesting (For some people) facts about ZX81

    Whilst attempting to write my own ZX81 emulator purely as a personal
    challenge, I have discovered a few interesting things about our beloved
    little machine.

    so i had the problem where the image in fast mode is shifted to the right a
    bit, after many frustrating hours of code checking and clock cycles counting
    i could not quite pin down the problem still sure it was my coding at fault.

    So out comes the scope and a real ZX81 issue 1 board 2C184E ULA, and found
    the following :-

    Hsync's and NMI pulses are 16 Clockcycles, NOT 15 as i always thought.
    There are 39 clock cycles after the end of Hsync before the first 2 bits of
    video is output
    there are 24 clock cycles after the last video bit before the start of
    Hsync.
    hence 16+39+128(video bits)+24 = 207.

    and now the most interesting bit that fixes the problem in the emulator.
    The Vsync pulse, which is controlled by software ends when the ZX81 executes
    the OUT ($FF),A instruction at memory location $277 which should take 11
    clock cycles.
    originally i had the vsync (in software) ending at the start of this 11
    clock cycles, which with hindsight is completely wrong, so a look at the z80
    technical specs shows that the /IORQ line is not active until the 2nd cycles
    of the third machine cycles for this instruction (M1 op-code-fetch 4 clocks,
    M2 operand-fetch 3 clocks, M3 IO-write 4 clocks [T1,T2, forced Tw, T3) so i
    re-jigged the code and things improved but it was not perfect, back to the
    Real ZX81 and a few frustrating minutes later (a dual timebase scope would
    have nailed it in seconds) because i could not get the trace to lock on the
    vsync at a high enough speed to see the /IORQ at the same time and what
    should i find ?

    Vsync ends on the rising edge of /IORQ of the OUT ($FE),A instruction this
    was totally unexpected for me, so that means v sync actually now end on
    falling edge of the last clock cycle.

    Another re-jig of my code, easier than the first re-jig since i only count
    clockcycles once for the in and out instructions. and all is well Slow and
    Fast displays are now in the same place.

    Regards Andy.






  2. Re: Some interesting (For some people) facts about ZX81

    Way back in the dark ages of dos, there was a z80 emulator which one could
    run cp/m on, and your post blew a few cobwebs off of a discussion similar to
    this about slight differences in how the z80 worked from how the
    manufacturer said it worked. Mostly timing things, but yes, they did affect
    all sorts of stuff when one tried to emulate the hardware.

    My brain hurts just reading your desscription....

    Brian

    --
    Brian Gaff - briang1@blueyonder.co.uk
    Note:- In order to reduce spam, any email without 'Brian Gaff'
    in the display name may be lost.
    Blind user, so no pictures please!
    "andy" wrote in message
    news:ExFUj.135$Nk5.72@newsfe15.ams2...
    > Whilst attempting to write my own ZX81 emulator purely as a personal
    > challenge, I have discovered a few interesting things about our beloved
    > little machine.
    >
    > so i had the problem where the image in fast mode is shifted to the right
    > a
    > bit, after many frustrating hours of code checking and clock cycles
    > counting
    > i could not quite pin down the problem still sure it was my coding at
    > fault.
    >
    > So out comes the scope and a real ZX81 issue 1 board 2C184E ULA, and found
    > the following :-
    >
    > Hsync's and NMI pulses are 16 Clockcycles, NOT 15 as i always thought.
    > There are 39 clock cycles after the end of Hsync before the first 2 bits
    > of
    > video is output
    > there are 24 clock cycles after the last video bit before the start of
    > Hsync.
    > hence 16+39+128(video bits)+24 = 207.
    >
    > and now the most interesting bit that fixes the problem in the emulator.
    > The Vsync pulse, which is controlled by software ends when the ZX81
    > executes
    > the OUT ($FF),A instruction at memory location $277 which should take 11
    > clock cycles.
    > originally i had the vsync (in software) ending at the start of this 11
    > clock cycles, which with hindsight is completely wrong, so a look at the
    > z80
    > technical specs shows that the /IORQ line is not active until the 2nd
    > cycles
    > of the third machine cycles for this instruction (M1 op-code-fetch 4
    > clocks,
    > M2 operand-fetch 3 clocks, M3 IO-write 4 clocks [T1,T2, forced Tw, T3) so
    > i
    > re-jigged the code and things improved but it was not perfect, back to the
    > Real ZX81 and a few frustrating minutes later (a dual timebase scope would
    > have nailed it in seconds) because i could not get the trace to lock on
    > the
    > vsync at a high enough speed to see the /IORQ at the same time and what
    > should i find ?
    >
    > Vsync ends on the rising edge of /IORQ of the OUT ($FE),A instruction
    > this
    > was totally unexpected for me, so that means v sync actually now end on
    > falling edge of the last clock cycle.
    >
    > Another re-jig of my code, easier than the first re-jig since i only count
    > clockcycles once for the in and out instructions. and all is well Slow and
    > Fast displays are now in the same place.
    >
    > Regards Andy.
    >
    >
    >
    >
    >




  3. Re: Some interesting (For some people) facts about ZX81

    On Thu, 8 May 2008 17:05:54 +0100, "andy" wrote:

    >Another re-jig of my code, easier than the first re-jig since i only count
    >clockcycles once for the in and out instructions. and all is well Slow and
    >Fast displays are now in the same place.


    Cool. Now your next project is to discover where flag bits 5+3 come
    from for the SCF and CCF opcodes because they certainly don't come
    from the A register (on an NEC clone at least) like the docs say.

    Get to it!

  4. Re: Some interesting (For some people) facts about ZX81


    "Woodster" wrote in message
    news:93p624dmu1idatq62j92na7fe8nultqtd9@4ax.com...
    > On Thu, 8 May 2008 17:05:54 +0100, "andy" wrote:
    >
    >>Another re-jig of my code, easier than the first re-jig since i only count
    >>clockcycles once for the in and out instructions. and all is well Slow and
    >>Fast displays are now in the same place.

    >
    > Cool. Now your next project is to discover where flag bits 5+3 come
    > from for the SCF and CCF opcodes because they certainly don't come
    > from the A register (on an NEC clone at least) like the docs say.


    i'll see what i can do think i have an NEC z80 knocking round in a spectrum
    somewhere, might be From MEMPTR which i have only very recently found out
    about and am in the process of implementing in my emulation,
    it IS very tedious making your own core emulation routine especially when
    your a novice programmer like me, this is by far the most complicated thing
    i have ever attempted, it sure aint pretty but once its stable-ish i'll
    release a beta. I think the main reason for doing it besides i like a good
    challenge was been a NOOB when it comes to 'C' i couldn;t quite get my head
    round how other core emulations where working so using someone else's GPLed
    core was no good to me, beside it's good fun learning 'C', and other
    emulators lacked the some feature i am after such as a real time memory
    explorer instead of having to either do a snapshot and open it with another
    piece of software, i also wanted a debugger that shows past code as well as
    upcoming code, also to show the effect of the next instruction without
    actually executing it, so you get a before and after look at the registers
    if you know what i mean.

    Andy
    >
    > Get to it!




  5. Re: Some interesting (For some people) facts about ZX81

    A day in the life of ZX81 (Well 64uS).

    on a real ZX81 i have already established where the active video signal
    occurs on each scan line in terms of clock cycles in relation to the end of
    the Hsync pulse but i decided to break it down further and after meticulous
    study am proud to present :- '' 64 uS in the life of a ZX81 Scan Line ! ''

    If we call the first Clock cycle immediatly after the end of Hsync Cycle 0
    (zero) this is what we get

    0 very last cycle of POP DE
    ----------
    1
    2
    3 RET Z
    4
    5
    ----------
    6
    7
    8
    9
    10
    11
    12 JR $0041
    13
    14
    15
    16
    17
    ----------
    18
    19
    20 ED PREFIX
    21
    ----------
    22
    23
    24 LD R,A
    25
    26
    ----------
    27
    28
    29 EI
    30
    ----------
    31
    32
    33 JP (HL)
    34
    ----------
    35
    36
    37 FIRST FORCED NOP
    38
    ---------- PIXEL DATA STARTS HERE ON RISING EDGE OF CYCLE 39.
    39
    40
    41 SECOND FORCED NOP
    42
    ----------
    ..
    .. MORE NOPS
    .. AND MORE VIDEO
    ..
    ..
    ----------
    159
    160
    161 THIRTY SECOND FORCED NOP
    162
    ----------
    163
    164
    165 HALT
    166
    ---------- PIXEL DATA STOPS HERE ON FALLING EDGE OF CYCLE 166
    167
    168 CPU FAKE NOP (CPU IS HALTED)
    169______ INT HAPPENS BETWEEN 169 AND 170
    170
    ----------
    171
    172
    173
    174
    175
    176
    177 INTERRUPT ACKNOWLEDGE
    178
    179
    180
    181
    182
    183
    ----------
    184
    185
    186 DEC C
    187
    ----------
    188
    189________HSYNC STARTS HERE BETWEEN 189 AND 190
    190
    191
    192
    193 JP NZ $0045
    194
    195
    196
    197
    ----------
    198
    199
    200
    201
    203 POP DE
    204
    205
    206________ HSYNC ENDS HERE BETWEEN 206 AND 0
    0
    ----------

    This information was obtained by carefull study of the M1 signal in relation
    to the video signal and then matching the M1 timmings with the instructions
    that should be executed during a scan line.

    Regards Andy



  6. Re: Some interesting (For some people) facts about ZX81

    On Thu, 8 May 2008 23:13:02 +0100, "andy" wrote:

    >
    >"Woodster" wrote in message
    >news:93p624dmu1idatq62j92na7fe8nultqtd9@4ax.com...
    >> On Thu, 8 May 2008 17:05:54 +0100, "andy" wrote:
    >>
    >> Cool. Now your next project is to discover where flag bits 5+3 come
    >> from for the SCF and CCF opcodes because they certainly don't come
    >> from the A register (on an NEC clone at least) like the docs say.

    >
    >i'll see what i can do think i have an NEC z80 knocking round in a spectrum
    >somewhere, might be From MEMPTR which i have only very recently found out
    >about and am in the process of implementing in my emulation


    Nope, those bits aren't from MEMPTR. They're more to do with the IR
    register pair than anything else. The only thing is that there's
    something else at work breaking up any evolving pattern and I can't
    figure out what it is. I did think it might be the temp acc. register
    but loading that with various values doesn't appear to make any
    difference suggesting it plays any part.

  7. Re: Some interesting (For some people) facts about ZX81


    "Woodster" wrote in message
    news:mrt8241icqidpqa3hp5thejutqgafmmohs@4ax.com...
    > On Thu, 8 May 2008 23:13:02 +0100, "andy" wrote:
    >
    >>
    >>"Woodster" wrote in message
    >>news:93p624dmu1idatq62j92na7fe8nultqtd9@4ax.com...
    >>> On Thu, 8 May 2008 17:05:54 +0100, "andy" wrote:
    >>>
    >>> Cool. Now your next project is to discover where flag bits 5+3 come
    >>> from for the SCF and CCF opcodes because they certainly don't come
    >>> from the A register (on an NEC clone at least) like the docs say.

    >>
    >>i'll see what i can do think i have an NEC z80 knocking round in a
    >>spectrum
    >>somewhere, might be From MEMPTR which i have only very recently found out
    >>about and am in the process of implementing in my emulation

    >
    > Nope, those bits aren't from MEMPTR. They're more to do with the IR
    > register pair than anything else. The only thing is that there's
    > something else at work breaking up any evolving pattern and I can't
    > figure out what it is. I did think it might be the temp acc. register
    > but loading that with various values doesn't appear to make any
    > difference suggesting it plays any part.


    Might i ask how you are testing this ?
    my preliminary tests using the following code give the expected results

    :START LD A,FF
    :LOOP CALL JUMP ;SETS MEMPTR TO A KNOWN VALUE
    :JUMP NOP
    :TEST SCF ;INSTRUCTION TO TEST
    DEC A
    JR NZ, LOOP
    :END RET

    this was run on a +3 using Hisofts monp3 and tried with 3 different CPU's

    1. Mostek (c) tc8637
    mk3880n-4
    z80-cpu

    2. zilog
    z8400a ps
    z80a
    8412

    3. nec japan 8239x5
    d780c -1

    each and every time results where as expected

    Regards Andy.




  8. Re: Some interesting (For some people) facts about ZX81

    On Fri, 9 May 2008 20:33:10 +0100, "andy" wrote:

    [b3/5 of Flags in SCF]

    >Might i ask how you are testing this ?
    >my preliminary tests using the following code give the expected results


    Firstly I'm back to believing that b3 is a straight copy of A again!

    For bit 5, if bit 5 of F (before SCF) is set and bit 5 of A, bit 5 of
    F is set after the opcode. The same is not always true if bit 5 of F
    is clear before the opcode executes, even if bit 5 of A is set.

    I & R registers also play a part. I know changes in the I register
    value change the pattern of results moreso than changes in R. I have
    no idea what is actually happening with those register values though.
    Furthermore, there's also something unknown playing a part too.
    Whatever that is, it is affected by the thermal state of the CPU. It
    affects things far more when cool, and much less so after warming.

    Confused? It's been frazzling my brain for a few weeks now!

    Anyhow, to get a better understanding of what happens, you need to run
    a loop which runs SCF for all possible input values for both A and F,
    then grab the values of F after the opcode. You'll start to see a
    pattern emerging (barring the small effect of the unknown I referred
    to earlier), then change I and/or R and watch yet another pattern, and
    another...

    Of course this might be specific to the NEC D780-C1. Maybe the Zilogs
    (and even other NECs) might simply copy them from A.

    Currently I've got it down to something like this:
    b5 = (A & 32) & ((F OR (something to do with IR) OR (unknown)) & 32)

    And that's no good to anyone!



  9. Re: Some interesting (For some people) facts about ZX81


    "Woodster" wrote in message
    news:c9a924pvrg2pe2im5tn32bi0sp8v9rp7up@4ax.com...
    > On Fri, 9 May 2008 20:33:10 +0100, "andy" wrote:
    >
    > [b3/5 of Flags in SCF]
    >
    >>Might i ask how you are testing this ?
    >>my preliminary tests using the following code give the expected results

    >
    > Firstly I'm back to believing that b3 is a straight copy of A again!
    >
    > For bit 5, if bit 5 of F (before SCF) is set and bit 5 of A, bit 5 of
    > F is set after the opcode. The same is not always true if bit 5 of F
    > is clear before the opcode executes, even if bit 5 of A is set.
    >
    > I & R registers also play a part. I know changes in the I register
    > value change the pattern of results moreso than changes in R. I have
    > no idea what is actually happening with those register values though.
    > Furthermore, there's also something unknown playing a part too.
    > Whatever that is, it is affected by the thermal state of the CPU. It
    > affects things far more when cool, and much less so after warming.
    >
    > Confused? It's been frazzling my brain for a few weeks now!
    >
    > Anyhow, to get a better understanding of what happens, you need to run
    > a loop which runs SCF for all possible input values for both A and F,
    > then grab the values of F after the opcode. You'll start to see a
    > pattern emerging (barring the small effect of the unknown I referred
    > to earlier), then change I and/or R and watch yet another pattern, and
    > another...
    >
    > Of course this might be specific to the NEC D780-C1. Maybe the Zilogs
    > (and even other NECs) might simply copy them from A.
    >
    > Currently I've got it down to something like this:
    > b5 = (A & 32) & ((F OR (something to do with IR) OR (unknown)) & 32)


    have you asked the Russians ??? they seem to know everything !

    in the mean time i'll rewrite some code to set the F, and IR to a known
    value before hand.

    i'm sure a long long time ago i read soemwhere about certain NEC PD780 had a
    bug with the refresh that stopped some games working correctly on the
    spectrums
    i wonder if this is related to that ? wish i could find whereever i read it,
    (maybe i just dreamed it).. LOL

    Andy

    > And that's no good to anyone!
    >
    >




  10. Re: Some interesting (For some people) facts about ZX81

    well i got this piece of code now on a spectrum +3

    ORG 32768
    DI
    LD BC,0
    LD DE,0
    LP LD A,B
    LD I,A
    LD A,C
    LD R,A
    PUSH DE
    PUSH DE
    POP AF
    AND A,40 ; REPLACE WITH 8 , OR 32 TO TEST JUST BIT 3 OR 5
    LD H,A ; STORE PREDICTED RESULT
    POP AF

    SCF ;INSTRUCTION UNDER TEST

    PUSH AF
    LD A,H
    POP HL ; GET THE RESULT INTO L
    LD H,A
    LD A,L
    AND 40 ;REPLACE WITH 8, OR 32 TO TEST JUST BIT 3 OR 5
    CP H
    JR NZ,FLT

    DEC DE
    LD A,E
    OR D
    JR NZ,LP

    DEC BC
    LD A,C
    OR B
    JR NZ.LP

    EI
    RET ;SUCCESS ALL COMBOS OK

    FLT LD A,B
    LD (STR),A
    LD A,C
    LD (STR+1),A
    LD A,D
    LD (STR+2),A
    LD A,E
    LD (STR+3),A
    EI
    RET ; FAILED

    STR DB 0,0,0,0

    and guess what monp3 SUCKS !!

    i can single step and it doesn;t fail
    but run it and it does very early on !
    on both bits 5 and 3 even when tested separatly

    so next thing is to start cycling just register at a time and recording the
    result 256 vals at a time
    this could be a long job !

    now the question is why hasn;t this been spotted before ?

    Andy





  11. Re: Some interesting (For some people) facts about ZX81


    "Woodster" wrote in message
    news:c9a924pvrg2pe2im5tn32bi0sp8v9rp7up@4ax.com...
    > On Fri, 9 May 2008 20:33:10 +0100, "andy" wrote:
    >
    > [b3/5 of Flags in SCF]
    >
    >>Might i ask how you are testing this ?
    >>my preliminary tests using the following code give the expected results

    >
    > Firstly I'm back to believing that b3 is a straight copy of A again!


    My tests have revealed that whilst most of the time this hold true under
    certain test conditions it is not always so.

    >
    > For bit 5, if bit 5 of F (before SCF) is set and bit 5 of A, bit 5 of
    > F is set after the opcode. The same is not always true if bit 5 of F
    > is clear before the opcode executes, even if bit 5 of A is set.
    >
    > I & R registers also play a part. I know changes in the I register
    > value change the pattern of results moreso than changes in R. I have
    > no idea what is actually happening with those register values though.
    > Furthermore, there's also something unknown playing a part too.
    > Whatever that is, it is affected by the thermal state of the CPU. It
    > affects things far more when cool, and much less so after warming.


    Temparature AND indeed varying the supply voltage affects this unknown
    quantity also.
    in some test conditions i found the results where almost random for Bit 5
    however placing a 10K pull down resistor on D5 (direct to cpu) almost made
    this randomness go away but certainly has an effect. also when you have AF
    set so that randomness is produced, usually when IR has nearly all of its
    bits set low, then when you increase the number of bits in IR set high
    (doesn't seem to matter which bits) then 3 bits high seems to be the
    threshold, as when 4 bits or more are set the output is nearly alway set
    (for the same AF conditions)

    What can we draw from these findings ? well it seems that sometimes the
    input to Bit 5 when the Flag register is modified seem to be left in some
    state of limbo, (internally tristated maybe?) and depending on the loading
    of other circuits within the CPU, or temparature changes, or supply voltage
    changes, can affect the result.

    It maybe that we can never truly emulate these bits for these instructions

    Mostly i have been using NEC processor in a TS1500, after that using the
    same NEC processor in issue 1 ZX81 and the results are different again !
    much less random i think this is to do with the fact that zx81 data lines
    are always loaded by resistors where as in the TS1500 they are buffered.

    Well It's been a fun 48 hours but I've had enough now

    >
    > Confused? It's been frazzling my brain for a few weeks now!


    YEP very !
    >
    > Anyhow, to get a better understanding of what happens, you need to run
    > a loop which runs SCF for all possible input values for both A and F,
    > then grab the values of F after the opcode. You'll start to see a
    > pattern emerging (barring the small effect of the unknown I referred
    > to earlier), then change I and/or R and watch yet another pattern, and
    > another...


    here is the code i ended up running

    0001 0000
    0002 0000 ;;
    0003 0000 ;; Compile with "tasm -80 -b program.asm program.p"
    0004 0000 ;;
    0005 0000
    0006 0000 #define TPORT $BF ;the port number
    0007 0000
    0008 0000 #define CDFLAG 16443 ;system var
    0009 0000
    0010 0000 #define DEBOUNCE 16423 ;systen var
    0011 0000
    0012 0000 #define TEST_BREAK $0F46
    0013 0000
    0014 0000 #define DB .byte
    0015 0000 #define db .byte ; TASM cross-assembler definitions
    0016 0000 #define dw .word
    0017 0000 #define DW .word
    0018 0000 #define ds .block
    0019 0000 #define org .org
    0020 0000 #define end .end
    0021 0000
    0022 4009 org $4009
    0023 4009
    0024 4009 ;= System variables
    ============================================
    0025 4009
    0026 4009 00 db 0 ;VERSN
    0027 400A 00 00 dw 0 ;E_PPC
    0028 400C FD 46 dw dfile ;D_FILE
    0029 400E FE 46 dw dfile+1 ;DF_CC
    0030 4010 16 47 dw var ;VARS
    0031 4012 00 00 dw 0 ;DEST
    0032 4014 17 47 dw var+1 ;E_LINE
    0033 4016 16 47 dw last-1 ;CH_ADD
    0034 4018 00 00 dw 0 ;X_PTR
    0035 401A 17 47 dw last ;STKBOT
    0036 401C 17 47 dw last ;STKEND
    0037 401E 00 db 0 ;BERG
    0038 401F 5D 40 dw membot ;MEM
    0039 4021 00 db 0 ;not used
    0040 4022 02 db 2 ;DF_SZ
    0041 4023 01 00 dw 1 ;S_TOP
    0042 4025 FF FF FF db $FF,$FF,$FF ;LAST_K
    0043 4028 37 db 55 ;MARGIN
    0044 4029 FD 46 dw dfile ;NXTLIN
    0045 402B 00 00 dw 0 ;OLDPPC
    0046 402D 00 db 0 ;FLAGX
    0047 402E 00 00 dw 0 ;STRLEN
    0048 4030 8D 0C dw $0C8D ;T_ADDR
    0049 4032 00 00 dw 0 ;SEED
    0050 4034 FF FF dw $FFFF ;FRAMES
    0051 4036 00 00 db 0,0 ;COORDS
    0052 4038 BC db $BC ;PR_CC
    0053 4039 21 18 db 33,24 ;S_POSN
    0054 403B 40 db 01000000B ;CDFLAG
    0055 403C ds 33 ;Print buffer
    0056 405D membot:
    0057 405D ds 30 ;Calculatorīs memory area
    0058 407B ds 2 ;not used
    0059 407D
    0060 407D ;= First BASIC line, asm code
    ==================================
    0061 407D
    0062 407D line0:
    0063 407D 00 00 db 0,0
    0064 407F 7C 06 dw dfile-$-2
    0065 4081 EA db $ea ; REM
    0066 4082
    0067 4082 ;====================================
    0068 4082 ; MY CODE STARTS
    0069 4082
    0070 4082 ; REMEBER TO RUN IN FAST MODE !
    0071 4082
    0072 4082 START
    0073 4082 F3 DI
    0074 4083 21 FC 40 LD HL,RESULT
    0075 4086 3A F7 40 LP2 LD A,(IVAL)
    0076 4089 ED 47 LD I,A
    0077 408B 3A F8 40 LD A,(FVAL)
    0078 408E 4F LD C,A
    0079 408F 06 00 LD B,0 ;THIS IS THE INITIAL TEST VALUE FOR A
    0080 4091
    0081 4091 ; LD HL,RESULT
    0082 4091
    0083 4091
    0084 4091
    0085 4091 C5 LOOP PUSH BC ;TEST VALUE FOR AF ON STACK
    0086 4092 78 LD A,B
    0087 4093

    chnage the following code to get your predicted value in
    the D register (Don't use BC or HL)

    0088 4093 PRE ;;POP AF ;ONLY 1 VAL STILL ON STACK
    0089 4093 B1 OR C ;A OR F (SO EVEN IF BITS 3 AND 5 ARE
    RESET (IN A) BUT ALREADY SET IN F)
    0090 4094 E6 28 AND $28 ;A NOWHAS ONLY BITS 5 AND 3
    0091 4096 57 LD D,A ;STORE IN D
    0092 4097

    load R to a known value at each itteration (also sets
    MEMPTR)
    0093 4097 3A F9 40 LD A,(RVAL)
    0094 409A ED 4F LD R,A ;R+1
    0095 409C F1 POP AF ;TEST VALUE IN AF, R+ 2
    0096 409D
    0097 409D 37 TEST SCF ;INSTRUCTION TO TEST (flags before or
    after R incremented ? (R+3 or maybe +4)

    next bit moves some bytes around without using BC or HL

    0098 409E 7A LD A,D ;PREDICTED FLAG BITS 5 + 3 IN A, WAS IN D
    0099 409F
    0100 409F F5 PUSH AF ;SAVE FLAGS WE DON;T CARE ABOUT A NOW
    0101 40A0 D1 POP DE ;GET FLAGS
    0102 40A1 ; AT THID POINT PRE IS IN A, FLAGS IN E
    0103 40A1 57 LD D,A ; PRE IN D AGAIN
    0104 40A2 7B LD A,E ;FLAGS IN A
    0105 40A3 E6 28 AND $28 ;ONLY KEEP BITS 5 + 3
    0106 40A5
    0107 40A5 BA CP D ;COMPARE WITH D
    0108 40A6 20 25 JR NZ,FAIL ; NOT AS EXPECTED !
    0109 40A8
    0110 40A8
    0111 40A8 04 LP3 INC B
    0112 40A9 C2 91 40 JP NZ,LOOP ;INNER LOOP
    0113 40AC
    0114 40AC 3A F8 40 LD A,(FVAL)
    0115 40AF 3C INC A
    0116 40B0 32 F8 40 LD (FVAL),A
    0117 40B3 C2 86 40 JP NZ,LP2 ;SECOND LEVEL
    0118 40B6
    0119 40B6 3A F7 40 LD A,(IVAL)
    0120 40B9 3C INC A
    0121 40BA 32 F7 40 LD (IVAL),A
    0122 40BD C2 86 40 JP NZ,LP2 ;THIRD LEVEL


    0129 40C0 SUCCESS
    0130 40C0 3E 1E LD A,$1E
    0131 40C2 ED 47 LD I,A ;RESTORE I REGISTER
    0132 40C4 21 00 00 LD HL,0
    0133 40C7 E5 PUSH HL
    0134 40C8 C1 POP BC
    0135 40C9 22 FA 40 LD (SUC),HL
    0136 40CC C9 RET
    0137 40CD
    0138 40CD FAIL ; HERE WE SAVE THE VALUES (6 BYTES)

    RETRIEVED LATER ON IN BASIC PROGRAM

    0139 40CD ; BC IS THE AF VALUE
    0140 40CD ; IVAL AND RVAL ARE IN MEMORY
    0141 40CD 77 LD (HL),A ;ACTUAL
    0142 40CE 23 INC HL
    0143 40CF 72 LD (HL),D ;PREDICTED
    0144 40D0 23 INC HL
    0145 40D1 70 LD (HL),B
    0146 40D2 23 INC HL
    0147 40D3 71 LD (HL),C
    0148 40D4 23 INC HL
    0149 40D5 3A F7 40 LD A,(IVAL)
    0150 40D8 77 LD (HL),A
    0151 40D9 23 INC HL
    0152 40DA 3A F9 40 LD A,(RVAL)
    0153 40DD 77 LD (HL),A
    0154 40DE 23 INC HL
    0155 40DF 11 FC 46 LD DE,RESEND ;END OF THE RESULT MEMORY BLOCK
    0156 40E2 A7 AND A ;CLEAR CARRY
    0157 40E3 E5 PUSH HL
    0158 40E4 ED 52 SBC HL,DE ;HL REACHED THE END YET ?
    0159 40E6 E1 POP HL
    0160 40E7 C2 A8 40 JP NZ,LP3 ;NO CARRY ON
    0161 40EA
    0162 40EA 3E 1E LD A,$1E
    0163 40EC ED 47 LD I,A
    0164 40EE 21 FF FF LD HL,65535
    0165 40F1 E5 PUSH HL
    0166 40F2 C1 POP BC
    0167 40F3 22 FA 40 LD (SUC),HL
    0168 40F6 C9 RET
    0169 40F7
    0170 40F7
    0171 40F7
    0172 40F7 00 IVAL DB 0
    0173 40F8 00 FVAL DB 0
    0174 40F9 00 RVAL DB 0
    0175 40FA
    0176 40FA
    0177 40FA 00 00 SUC DW 0
    0178 40FC
    0179 40FC RESULT .block 1536
    0180 46FC RESEND
    0181 46FC
    0182 46FC
    0183 46FC ; MY CODE ENDS
    0184 46FC ;====================================
    0185 46FC
    0186 46FC 76 db $76 ;N/L
    0187 46FD
    0188 46FD ;- Display
    file --------------------------------------------
    0189 46FD
    0190 46FD dfile:
    0191 46FD 76 db $76
    0192 46FE 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
    0192 4704 7676
    0193 4706 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
    0193 470C 7676
    0194 470E 767676767676 db $76,$76,$76,$76,$76,$76,$76,$76
    0194 4714 7676
    0195 4716
    0196 4716 ;-
    BASIC-Variables ----------------------------------------
    0197 4716
    0198 4716 var:
    0199 4716 80 db $80
    0200 4717
    0201 4717 ;- End of program area ----------------------------
    0202 4717
    0203 4717 last:
    0204 4717
    0205 4717 end tasm: Number of errors = 0

    >
    > Of course this might be specific to the NEC D780-C1. Maybe the Zilogs
    > (and even other NECs) might simply copy them from A.
    >
    > Currently I've got it down to something like this:
    > b5 = (A & 32) & ((F OR (something to do with IR) OR (unknown)) & 32)
    >
    > And that's no good to anyone!
    >
    >


    Regards Andy



  12. Re: Some interesting (For some people) facts about ZX81

    On Fri, 9 May 2008 23:11:45 +0100, "andy" wrote:

    [snip code]

    >i can single step and it doesn;t fail
    >but run it and it does very early on !
    >on both bits 5 and 3 even when tested separatly
    >
    >so next thing is to start cycling just register at a time and recording the
    >result 256 vals at a time
    >this could be a long job !


    And, for me at least, running the code with the same register values
    repeatedly can still give different results due to this unknown part
    of the equation.

    >now the question is why hasn;t this been spotted before ?


    Stuart Brady first discovered it and mentioned it in the tech wiki:


    The results on the Zilog chip were different to those from the NEC but
    it'd be interesting to see this retested on the Zilog with different
    I/R register values to see if there's still some oddities happening in
    those CPUs.

    One other thing on the NEC is that if you pair groups of CCF/SCF (did
    I mention CCF behaves the same?), then bits 5+3 are simply copies from
    A, AFAICT.

    My latest z80tests code uses CCF/SCF opcodes for the SCF test, and
    SCF/CCF for the CCF test and gives the expected result.


    It appears that inserting any opcode between these pair of opcodes
    that alter the flags in any way brings back the strange behaviour
    again.

  13. Re: Some interesting (For some people) facts about ZX81

    On Sun, 11 May 2008 14:19:44 +0100, "andy" wrote:

    >Temparature AND indeed varying the supply voltage affects this unknown
    >quantity also.
    >in some test conditions i found the results where almost random for Bit 5
    >however placing a 10K pull down resistor on D5 (direct to cpu) almost made
    >this randomness go away but certainly has an effect. also when you have AF
    >set so that randomness is produced, usually when IR has nearly all of its
    >bits set low, then when you increase the number of bits in IR set high
    >(doesn't seem to matter which bits) then 3 bits high seems to be the
    >threshold, as when 4 bits or more are set the output is nearly alway set
    >(for the same AF conditions)
    >
    >What can we draw from these findings ? well it seems that sometimes the
    >input to Bit 5 when the Flag register is modified seem to be left in some
    >state of limbo, (internally tristated maybe?) and depending on the loading
    >of other circuits within the CPU, or temparature changes, or supply voltage
    >changes, can affect the result.
    >
    >It maybe that we can never truly emulate these bits for these instructions
    >
    >Mostly i have been using NEC processor in a TS1500, after that using the
    >same NEC processor in issue 1 ZX81 and the results are different again !
    >much less random i think this is to do with the fact that zx81 data lines
    >are always loaded by resistors where as in the TS1500 they are buffered.
    >
    >Well It's been a fun 48 hours but I've had enough now


    Well, as long as you had fun

    Your discoveries have, of course, helped me decide to leave my current
    5+3 flags behaviour as-is!

    Cheers for looking at this.

+ Reply to Thread