Z80 Protocol Decoder

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Z80 Protocol Decoder

Post by BigEd » Mon Aug 06, 2018 10:05 am

hoglet wrote:
Sun Aug 05, 2018 8:52 pm
BigEd wrote:
Sun Aug 05, 2018 8:35 pm
The answer may be here - the only path to read IR is through an incrementer:
Perfect, that explains it.
Sorry, I was quite wrong! The extra increment is caused by the ED prefix - LD A, R is a prefixed instruction. The prefix gives you an extra M1 cycle, apparently.

Did you also see this:
NEW From Alvin Albrecht:
[The effect of interrupts upon the R register is as follows:

An NMI performs a fake opcode fetch during acknowledge (ie increments R by 1).
Following assertion of /M1 and /IORQ during a maskable interrupt acknowledge, the z80 performs a refresh (R increased by 1).
In mode 0, following the maskable interrupt acknowledge, the z80 inserts the instruction provided by the peripheral (likely a RST or possibly a CALL where the peripheral will provide the address when the time comes). Increase R by 1 more.
In mode 1, the z80 executes a RST #38 internally. Don't increase R by any more.
In mode 2, address of interrupt routine fetched through memory read cycles. Don't increase R by any more.]

User avatar
1024MAK
Posts: 8010
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Z80 Protocol Decoder

Post by 1024MAK » Mon Aug 06, 2018 12:26 pm

From Zilog's own documention:

Z80 Manual
  • RESET.
    Reset (input, active Low). RESET initializes the CPU as follows: it resets the interrupt enable flip-flop, clears the Program Counter and registers I and R, and sets the interrupt status to Mode 0. During reset time, the address and data bus enter a high-impedance state, and all control output signals enter an inactive state. RESET must be active for a minimum of three full clock cycles before a reset operation is complete.
Mark

User avatar
jonb
Posts: 2284
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England
Contact:

Re: Z80 Protocol Decoder

Post by jonb » Mon Aug 06, 2018 12:47 pm

hoglet wrote:
Mon Aug 06, 2018 8:08 am
jonb wrote:
Mon Aug 06, 2018 6:47 am
Sorry for the thickie question, but is the protocol analyser like the Zicon logic analyser by any chance?
Yes, in that it works as a "inverse assembler" (like Zicon and certain HP logic analyzers).

But it improves on those in two respects:
- it requires fewer connection (just the data bus and a few control signals, not the whole address bus)
- it also infers the values of all of the internal registers and flags (because it runs a Z80 emulation in parallel)

Do you have any broken Z80-based machines?

Dave
Yes, Dave - I have LOADs of them, as you might expect, but these are the ones in "sick bay" right now:
  • The P2000C is not booting from floppy any more (as before; plus, the monitor board has had a bunch of RAM stolen off it)
  • I've got a few broken Speccys, likely to be "the usual suspect" type breakages.
  • Two Superbrains (one is the CCH machine which has failed RAM, the other is mine which does weird things when you attempt to copy stuff using PIP).
  • A ZX81 that only works if the 16k RAMPACK is plugged in (it's not been tried for years now, so may be completely broken.)
  • An Amstrad 6128 which is proper dead. I do have a second on that works, though.
I think that's it. All the other Z-80 machines (including my "beloved" PCWs, ha!) are working AFAIK, which is pretty amazing when you consider how many of them there are. Probably not as many as Mark has, though!

I am fortunate as I have a Tauntek Z80 ICE (no longer available due to unavailability of the 5v CPLD it uses) which has made the Zicon more or less redundant. I can't remember if the Zicon shows the register values or not, it's been that long since I used it. I think inferring the address bus is definitely a bit clever, but I suspect you can tell it from the (emulated) Z80 core? Sneaky...

All I need now is (lots) more time. I'm kind of off my game with retrocomputing at the moment and need to restore my enthusiasm.
Last edited by jonb on Mon Aug 06, 2018 12:55 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 1:37 pm

jonb wrote:
Mon Aug 06, 2018 12:47 pm
I am fortunate as I have a Tauntek Z80 ICE (no longer available due to unavailability of the 5v CPLD it uses) which has made the Zicon more or less redundant.
I think the main difference with the Protocol Decoder is it is completely non-intrusive (apart from a small mount of additional loading on each of the signals it's monitoring).
jonb wrote:
Mon Aug 06, 2018 12:47 pm
I can't remember if the Zicon shows the register values or not, it's been that long since I used it.
I would be very interested if it did.
jonb wrote:
Mon Aug 06, 2018 12:47 pm
I think inferring the address bus is definitely a bit clever, but I suspect you can tell it from the (emulated) Z80 core? Sneaky...
Yes, the PC does come from the emulated Z80.

The emulation part is something I had to write from scratch, because it has to deal with and correctly propagate, unknown values. So if the state of a flag, for example, is 0, 1 or ? (unknown). If the carry flag is unknown, and a JR C instruction is executed, the PC then becomes unknown. This uncertainty is not something an existing emulator needs to deal with.

Dave

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Z80 Protocol Decoder

Post by Elminster » Mon Aug 06, 2018 1:46 pm

Elminster wrote:
Sat Aug 04, 2018 8:06 pm
I of course have the z80 Powered RC2014, basically configured to bootstrap to msdos, I plan at some point to get cp/m running on it.

When I get some time I will see if I can hook it all up.
I will have to solder on the extra optional board connctors first, so that I can put the Z80 board at the edge so as to have room to fit the piggy back clip thingy me bob.

User avatar
jonb
Posts: 2284
Joined: Sat May 21, 2011 12:42 pm
Location: South Coast of England
Contact:

Re: Z80 Protocol Decoder

Post by jonb » Mon Aug 06, 2018 2:33 pm

hoglet wrote:
Mon Aug 06, 2018 1:37 pm
jonb wrote:
Mon Aug 06, 2018 12:47 pm
I can't remember if the Zicon shows the register values or not, it's been that long since I used it.
I would be very interested if it did.
Just checked - it doesn't.. pfft. It's one of those oddball things that's totally useless, until you need it.
Last edited by jonb on Mon Aug 06, 2018 2:36 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 2:55 pm

In the last day or two I've been focusing on testing.

I've been able to run Patrick Rak's emulator test suite on my Spectrum +2 and capture a trace of the results:
- this includes 152 test cases
- test takes 5-6 minutes to run and produces a 2.24GB capture file
- Z80 Decode takes 7-8 minutes to run and produces a 24.3GB output file

Here's a list of the test cases:

Code: Select all

     1   SELF TEST
     2   SCF
     3   CCF
     4   SCF+CCF
     5   CCF+SCF
     6   DAA
     7   CPL
     8   NEG
     9   NEG'
    10   ADD A,N
    11   ADC A,N
    12   SUB A,N
    13   SBC A,N
    14   AND N
    15   XOR N
    16   OR N
    17   CP N
    18   ALO A,A
    19   ALO A,[B,C]
    20   ALO A,[D,E]
    21   ALO A,[H,L]
    22   ALO A,(HL)
    23   ALO A,[HX,LX]
    24   ALO A,[HY,LY]
    25   ALO A,(XY)
    26   RLCA
    27   RRCA
    28   RLA
    29   RRA
    30   RLD
    31   RRD
    32   RLC A
    33   RRC A
    34   RL A
    35   RR A
    36   SLA A
    37   SRA A
    38   SLIA A
    39   SRL A
    40   RLC [R,(HL)]
    41   RRC [R,(HL)]
    42   RL [R,(HL)]
    43   RR [R,(HL)]
    44   SLA [R,(HL)]
    45   SRA [R,(HL)]
    46   SLIA [R,(HL)]
    47   SRL [R,(HL)]
    48   SRO (XY)
    49   SRO (XY),R
    50   INC A
    51   DEC A
    52   INC [R,(HL)]
    53   DEC [R,(HL)]
    54   INC X
    55   DEC X
    56   INC (XY)
    57   DEC (XY)
    58   INC RR
    59   DEC RR
    60   INC XY
    61   DEC XY
    62   ADD HL,RR
    63   ADD IX,RR
    64   ADD IY,RR
    65   ADC HL,RR
    66   SBC HL,RR
    67   BIT N,A
    68   BIT N,(HL)
    69   BIT N,[R,(HL)]
    70   BIT N,(XY)
    71   BIT N,(XY),-
    72   SET N,A
    73   SET N,(HL)
    74   SET N,[R,(HL)]
    75   SET N,(XY)
    76   SET N,(XY),R
    77   RES N,A
    78   RES N,(HL)
    79   RES N,[R,(HL)]
    80   RES N,(XY)
    81   RES N,(XY),R
    82   LDI
    83   LDD
    84   LDIR
    85   LDDR
    86   CPI
    87   CPD
    88   CPIR
    89   CPDR
    90   IN A,(N)
    91   IN R,(C)
    92   IN (C)
    93   INI
    94   IND
    95   INIR
    96   INDR
    97   OUT (N),A
    98   OUT (C),R
    99   OUT (C),0
   100   OUTI
   101   OUTD
   102   OTIR
   103   OTDR
   104   JP NN
   105   JP CC,NN
   106   JP (HL)
   107   JP (XY)
   108   JR N
   109   JR CC,N
   110   DJNZ N
   111   CALL NN
   112   CALL CC,NN
   113   RET
   114   RET CC
   115   RETN
   116   RETI
   117   RETI/RETN
   118   PUSH+POP RR
   119   POP+PUSH AF
   120   PUSH+POP XY
   121   EX DE,HL
   122   EX AF,AF'
   123   EXX
   124   EX (SP),HL
   125   EX (SP),XY
   126   LD [R,(HL)],[R,(HL)]
   127   LD [X,(XY)],[X,(XY)]
   128   LD R,(XY)
   129   LD (XY),R
   130   LD [R,(HL)],N
   131   LD X,N
   132   LD (XY),N
   133   LD A,([BC,DE])
   134   LD ([BC,DE]),A
   135   LD A,(NN)
   136   LD (NN),A
   137   LD RR,NN
   138   LD XY,NN
   139   LD HL,(NN)
   140   LD XY,(NN)
   141   LD RR,(NN)
   142   LD (NN),HL
   143   LD (NN),XY
   144   LD (NN),RR
   145   LD SP,HL
   146   LD SP,XY
   147   LD I,A
   148   LD R,A
   149   LD A,I
   150   LD A,R
   151   EI+DI
   152   IM N
After fixing a few bugs, I'm now able to decode this trace without any failures being flagged by my Z80 emulation code.

So I'm pretty happy now that the emulation is in good shape.

There are just two cases I know of now where I'm not able to predict the correct values for the undocumented F5/F3 flags (a.k.a. YF and XF):
- following SCF (Set carry) or CCF (Complement carry)
- following LDIR (and probably LDDR/LDI/LDD)

The first case (with SCF/CCF) I understand. It turns out the setting of the undocumented F5/F3 flags in SCF and CCF actually depends on whether the preceding instruction modified the flags or not. This is described in this post. I don't see any problem in implementing this, I just haven't done so yet,

The second case (with LDIR) has me very confused. It seems that the current understanding is that F5 and F3 flags take on bits 1 and 3 of (data + A). I'm doing this, and still seeing errors.

Code: Select all

 FETCH 0 0 1 0 1 1 1 0 ed * 
 FETCH 0 0 1 0 1 1 1 0 b0 * 
 MEMRD 1 0 1 0 1 1 1 0 38 * : Rd=38
 MEMWR 1 1 0 0 1 1 1 0 38 * : Wd=38
0E82 : ED B0           : LDIR                 : 21/ 0 : A=38 F= Z0 0V   BC=00B0 DE=5A50 HL=5A4F IX=F7FF IY=5C3A SP=FF50

 FETCH 0 0 1 0 1 1 1 0 ed * 
 FETCH 0 0 1 0 1 1 1 0 b0 * 
 MEMRD 1 0 1 0 1 1 1 0 38 * : Rd=38
 MEMWR 1 1 0 0 1 1 1 0 38 * : Wd=38
0E82 : ED B0           : LDIR                 : 23/ 0 : A=38 F= Z0 0V   BC=00AF DE=5A51 HL=5A50 IX=F7FF IY=5C3A SP=FF50

INTACK 0 1 1 1 0 1 1 0 ff * 
 MEMWR 1 1 0 0 1 1 1 0 0e * 
 MEMWR 1 1 0 0 1 1 1 0 82 * : Rd=38
0E82 :                 : INT                  : 11/ 0 : A=38 F= Z0 0V   BC=00AF DE=5A51 HL=5A50 IX=F7FF IY=5C3A SP=FF4E

 FETCH 0 0 1 0 1 1 1 0 f5 * : Wd=38
 MEMWR 1 1 0 0 1 1 1 0 38 * 
 MEMWR 1 1 0 0 1 1 1 0 4c * 
0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=00AF DE=5A51 HL=5A50 IX=F7FF IY=5C3A SP=FF4C : fail
If you look at the flags value in the final line (marked fail), you can see the F3 flags has been "corrected" from 0 to 1 based on what was PUSHed to memory. This represents reality, i.e. what the Z80 actually set them to.

The unofficial documentation says these should be based on (data + A) = (0x38 + 0x38) = 0x70. So F5 should be bit 1 and F3 should be bit 3, both 0. That how I'm calculating them. But it seems the Z80 is actually doing something different, as the value pushed shows F3 is actually 1.

My implementation of this is quite simple:

Code: Select all

   // Set the flags, see: page 16 of http://www.z80.info/zip/z80-documented.pdf
   if (reg_a >= 0) {
      int result = reg_a + arg_read;
      flag_f5 = (result >> 1) & 1;
      flag_f3 = (result >> 3) & 1;
   } else {
      flag_f5 = -1;
      flag_f3 = -1;
   }
For comparison, here's the same code from MAME:

Code: Select all

	F &= SF | ZF | CF;
	if ((A + io) & 0x02) F |= YF; /* bit 1 -> flag 5 */
	if ((A + io) & 0x08) F |= XF; /* bit 3 -> flag 3 */
(YF is F5 and XF is F3).

I'm sure I'm missing something here, but I can't for the life of me figure it out.

Dave
Last edited by hoglet on Mon Aug 06, 2018 3:04 pm, edited 4 times in total.

gdevic
Posts: 4
Joined: Mon Aug 06, 2018 1:13 pm
Contact:

Re: Z80 Protocol Decoder

Post by gdevic » Mon Aug 06, 2018 3:13 pm

What a great thread!

The "special reset" is described in the "US4486827" patent: https://drive.google.com/file/d/0BykuPm ... mMwcVlOWWM
It is used for breakpoints and is the reason a real reset cycle needs to be several clocks long.

When I was implementing A-Z80, I have used schematics from this (and other) available patents to arrive at the exact timing behaviour (which had to be just slightly modified once I swapped latches with flops ( http://baltazarstudios.com/z80-cpu/ ). The model is otherwise exact except for those two unused flags bits which, I believe, also differ based on the Z80 variations and technology (NMOS/CMOS).

During that work I also fixed a couple of bugs and added T-states to https://drive.google.com/file/d/0BykuPm ... VJKLUJhZ1U
I have arrived to correct timing in somewhat similar way, by driving a Z80 using an Arduino board.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 4:12 pm

gdevic wrote:
Mon Aug 06, 2018 3:13 pm
When I was implementing A-Z80, I have used schematics from this (and other) available patents to arrive at the exact timing behaviour (which had to be just slightly modified once I swapped latches with flops ( http://baltazarstudios.com/z80-cpu/ ). The model is otherwise exact except for those two unused flags bits which, I believe, also differ based on the Z80 variations and technology (NMOS/CMOS).
Welcome to Stardot.

I've been using your cycles traces quite a lot in the last week, so thank you.

I was aware the SCF/CCF flags behaviour varied between Z80 part types - I think that was first described here:
https://www.worldofspectrum.org/forums/ ... ent_668950

But I thought that the LDIR behaviour was uncontroversial and everyone agreed. But it seems my results suggest it may not be. I'm sure this is a mistake somewhere on my part, but I don't see what it is yet.

The most likely explanation is bus sampling errors, but it was consistent between three runs.

Dave
Last edited by hoglet on Mon Aug 06, 2018 4:20 pm, edited 2 times in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 4:19 pm

Ed, if you are up for trying another small program on the Z80, could you try this one please?

Code: Select all

 10 DIM code  &100   ; reserve some code space
 20 DIM data1 &100   ; reserve some data space to read from
 30 DIM data2 &100   ; reserve some data space to write to
 40 P%=code
 50[OPT 0
 60 LD A, &38        ; value to be copied
 70 LD (data1), A    ; store this in data1
 80 LD HL, data1     ; src for LDI
 90 LD DE, data2     ; dst for LDI
100 LDI              ; copy one byte: (DE) <= (HL); DE++; HL++
110 PUSH AF          ; save the flags
120 POP  HL          ; HL is returned as the result of USR()
130 RET
140]
150 PRINT ~USR(code) AND &FFFF
Hopefully I have the syntax correct for Z80 BBC Basic.

Dave

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Z80 Protocol Decoder

Post by BigEd » Mon Aug 06, 2018 4:32 pm

Mutatis mutandis, as we used to say:

Code: Select all

>L.
   10 DIM code  &100   :REM reserve some code space
   20 DIM data1 &100   :REM reserve some data space to read from
   30 DIM data2 &100   :REM reserve some data space to write to
   40 P%=code
   50 [OPT 0
   60 LD A, &38        :\ value to be copied
   70 LD (data1), A    :\ store this in data1
   80 LD HL, data1     :\ src for LDI
   90 LD DE, data2     :\ dst for LDI
  100 LDI              :\ copy one byte; (DE) <= (HL); DE++; HL++
  110 PUSH AF          :\ save the flags
  120 POP  HL          :\ HL is returned as the result of USR()
  130 RET
  140 ]
  150 PRINT ~USR(code)
>RUN
  38040000

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 4:41 pm

That was quick!
BigEd wrote:
Mon Aug 06, 2018 4:32 pm

Code: Select all

  38040000
OK, so F was 04 (00000100) so bit 5 and 3 were both zero, which agrees with the conventional model.

The specific example I saw of this mis-behaving was LDIR interrupted by a normal interrupt (part of the boot of the Spectrum +2). It's only because of the interrupt that the flags become "Visible" as they are pushed to the stack.

Hmmm.... this is going to be a tricky one.

Lots of possibilities:
- the interrupt is coming into play here and affecting the flags
- LDIR is different from LDI
- multiple consecutive LDI changes things
- the BC count plays a role somehow
- user error on my parts somehow

Let me see if I can find an example that goes wrong that doesn't involve an interrupt.

Dave
Last edited by hoglet on Mon Aug 06, 2018 4:42 pm, edited 1 time in total.

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Z80 Protocol Decoder

Post by jgharston » Mon Aug 06, 2018 5:29 pm

Richard Russell wrote:
Mon Aug 06, 2018 9:09 am
It may be that some Z80s do (... clear all registers....), perhaps from specific manufacturers or of various design revisions, but the one I used in that device clearly didn't
There could well be differences between different models/manufacturers. The documentation only states that RESET gives IR=0, PC=0, different manufacturers may have chose to also zero the other registers. I've certainly seen documentation that claims that SP=FFFF on RESET, which could be for certain types. I'll have to see if I can track it down.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Z80 Protocol Decoder

Post by Richard Russell » Mon Aug 06, 2018 5:48 pm

BigEd wrote:
Mon Aug 06, 2018 4:32 pm
60 LD A, &38 :\ value to be copied
The semicolon comment delimiter, as listed by the OP, is accepted by BBC BASIC (Z80) isn't it? I have of course nabbed it as the 'line continuation' character in my more recent versions of BBC BASIC, so I prefer not to use it in the context of the assembler.

Richard.

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Z80 Protocol Decoder

Post by jgharston » Mon Aug 06, 2018 5:50 pm

jgharston wrote:
Mon Aug 06, 2018 5:29 pm
Richard Russell wrote:
Mon Aug 06, 2018 9:09 am
It may be that some Z80s do (... clear all registers....), perhaps from specific manufacturers or of various design revisions, but the one I used in that device clearly didn't
There could well be differences between different models/manufacturers. The documentation only states that RESET gives IR=0, PC=0, different manufacturers may have chose to also zero the other registers. I've certainly seen documentation that claims that SP=FFFF on RESET, which could be for certain types. I'll have to see if I can track it down.
Ah, here we are:
(Matt) found that AF and SP are always set to FFFFh after a reset, and all other registers are undefined (different depending on how long the CPU has been powered off, different for different Z80 chips). Of course the PC should be set to 0 after a reset, and so should the IFF1 and IFF2 flags (otherwise strange things could happen). Also since the Z80 is 8080 compatible, interrupt mode is probably 0.

Zilog documentation does say that RESET results in IM 0, so RESET gives IFF=0, IM=0, IR=0, PC=0, SP=FFFF, AF=FFFF and everything else undefined (but probably only undefined in the strictest sense when coming from a power-on - RESET does nothing to them, which from power on will most likely be random contents, and at other times will be whatever they happened to have). An interesting question is if AF' is also set to FFFF. Nobody seems to have tested for this.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Z80 Protocol Decoder

Post by jgharston » Mon Aug 06, 2018 5:56 pm

Richard Russell wrote:
Mon Aug 06, 2018 5:48 pm
BigEd wrote:
Mon Aug 06, 2018 4:32 pm
60 LD A, &38 :\ value to be copied
The semicolon comment delimiter, as listed by the OP, is accepted by BBC BASIC (Z80) isn't it? I have of course nabbed it as the 'line continuation' character in my more recent versions of BBC BASIC, so I prefer not to use it in the context of the assembler.
And is accepted in the 6502 assembler due to the accident of it being seen as superflous stuff at the end of the instruction:

Code: Select all

>10P%=&900
>20[OPT 3
>30LDA #0 ; hello
>RUN
0900       OPT 3
0900 A9 00 LDA #0 ; hello
>
Last edited by jgharston on Mon Aug 06, 2018 5:56 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Z80 Protocol Decoder

Post by BigEd » Mon Aug 06, 2018 6:03 pm

Richard Russell wrote:
Mon Aug 06, 2018 5:48 pm
BigEd wrote:
Mon Aug 06, 2018 4:32 pm
60 LD A, &38 :\ value to be copied
The semicolon comment delimiter, as listed by the OP, is accepted by BBC BASIC (Z80) isn't it?
Yes, it is. I'd meandered my way to an acceptable syntax, and not found the optimum route.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 6:24 pm

Ed,

What flavour of Z80 does your Z80 Second Processor contain?

Dave

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Z80 Protocol Decoder

Post by Richard Russell » Mon Aug 06, 2018 6:25 pm

jgharston wrote:
Mon Aug 06, 2018 5:50 pm
RESET does nothing to them, which from power on will most likely be random contents, and at other times will be whatever they happened to have...
I think it's highly confusing to conflate 'reset' with 'power on'. By 'reset' I mean pulsing the reset pin of the chip, with no interruption of power.

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Z80 Protocol Decoder

Post by BigEd » Mon Aug 06, 2018 6:44 pm

hoglet wrote:
Mon Aug 06, 2018 6:24 pm
Ed,

What flavour of Z80 does your Z80 Second Processor contain?

Dave
Ah, good question. It turns out to be an SGS. The label is rather unclear, but that much is certain.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 6:52 pm

BigEd wrote:
Mon Aug 06, 2018 6:44 pm
Ah, good question. It turns out to be an SGS. The label is rather unclear, but that much is certain.
OK, I shall put one of those in my Spectrum +2 and re-measure. Back in a mo....

colonel32
Posts: 55
Joined: Wed Jan 18, 2017 7:59 pm
Location: USA
Contact:

Re: Z80 Protocol Decoder

Post by colonel32 » Mon Aug 06, 2018 6:57 pm

hoglet wrote:
Mon Aug 06, 2018 2:55 pm
The second case (with LDIR) has me very confused. It seems that the current understanding is that F5 and F3 flags take on bits 1 and 3 of (data + A). I'm doing this, and still seeing errors.
The NEC Z80s behave differently from the Zilog ones. And possibly others like Mostek behave differently again. Certainly with respect to undocumented implementation-specific behaviour like F3/5, since they reverse-engineered the Zilog hardware rather than working from supplied designs.

If you're analysing chips, you should probably do one of each, and stick to a particular implementation consistently, or have it switchable.

I believe Patrik's tests primarily target the NEC version.
Last edited by colonel32 on Mon Aug 06, 2018 7:01 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 7:25 pm

Here's my selection of Z80 related chips:
IMG_1425.JPG
I've tried the following:
- Zilog Z0840004PSC (the one initially fitted)
- SGS Z8400AB1
- ST Z84C00HB6
- Mostek MK3880BN-6
- Sharp dmb@quadhog:~/atom/Z80Decoder/SpectrumPlus2$ grep -n fail run1.log

For each I took a trace of the Spectrum booting and ran it through the decoder.

Each produced exactly the same similar failures, with incorrect F5/F3 flags after an interrupted LDIR.

Code: Select all

250836:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=00AF DE=5A51 HL=5A50 IX=F7FF IY=5C3A SP=FF4C : fail
262466:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 0V C BC=03DA DE=E126 HL=E125 IX=F7FF IY=5C3A SP=5BF7 : fail
351148:5B00 : F5              : PUSH AF              : 11/ 0 : A=00 F= Z0 1V C BC=0001 DE=F0F4 HL=0038 IX=FD98 IY=5C3A SP=5BE3 : fail

dmb@quadhog:~/atom/Z80Decoder/SpectrumPlus2$ grep -n fail run7_sgs.log
250873:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=008A DE=5A76 HL=5A75 IX=3FBE IY=5C3A SP=FF4C : fail
262467:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 0V C BC=039B DE=E165 HL=E164 IX=3FBE IY=5C3A SP=5BF7 : fail

dmb@quadhog:~/atom/Z80Decoder/SpectrumPlus2$ grep -n fail run8_st_cmos.log
259499:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=009C DE=5A64 HL=5A63 IX=FFFF IY=5C3A SP=FF4C : fail
271100:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 0V C BC=03A6 DE=E15A HL=E159 IX=FFFF IY=5C3A SP=5BF7 : fail
359844:5B00 : F5              : PUSH AF              : 11/ 0 : A=00 F= Z0 1V C BC=0001 DE=F0F4 HL=0038 IX=FD98 IY=5C3A SP=5BE3 : fail

dmb@quadhog:~/atom/Z80Decoder/SpectrumPlus2$ grep -n fail run9_mostek.log
250844:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=00A7 DE=5A59 HL=5A58 IX=FFBF IY=5C3A SP=FF4C : fail
262475:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 0V C BC=03D1 DE=E12F HL=E12E IX=FFBF IY=5C3A SP=5BF7 : fail
351206:5B00 : F5              : PUSH AF              : 11/ 0 : A=00 F= Z0 1V C BC=0007 DE=F0D2 HL=0038 IX=FD98 IY=5C3A SP=5BE3 : fail

dmb@quadhog:~/atom/Z80Decoder/SpectrumPlus2$ grep -n fail run10_sharp.log
251027:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 1V   BC=0093 DE=5A6D HL=5A6C IX=FFFD IY=5C3A SP=FF4C : fail
262621:0038 : F5              : PUSH AF              : 11/ 0 : A=38 F= Z0 0V C BC=03A4 DE=E15C HL=E15B IX=FFFD IY=5C3A SP=5BF7 : fail
351363:5B00 : F5              : PUSH AF              : 11/ 0 : A=00 F= Z0 1V C BC=0001 DE=F0F4 HL=0038 IX=FD98 IY=5C3A SP=5BE3 : fail
Now, they are not identical because I don't think the VSync interrupt is consistent.

But they are close enough....

So I don't think it's just a manufacturer specific thing.

Dave
Last edited by hoglet on Thu Aug 09, 2018 5:38 pm, edited 3 times in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Mon Aug 06, 2018 7:31 pm

colonel32 wrote:
Mon Aug 06, 2018 6:57 pm
The NEC Z80s behave differently from the Zilog ones. And possibly others like Mostek behave differently again. Certainly with respect to undocumented implementation-specific behaviour like F3/5, since they reverse-engineered the Zilog hardware rather than working from supplied designs.

If you're analysing chips, you should probably do one of each, and stick to a particular implementation consistently, or have it switchable.

I believe Patrik's tests primarily target the NEC version.
I'll try to find a NEC one (I think there is one in my ZX81).

Also, It's not that Patrik's test are actually failing (they are not, at least not on the original Zilog).

It's just my Z80 Decoder that is mis-predicting the F5/F3 flags when an LDIR is interrupted, but so far only in this specific case.

Dave
Last edited by hoglet on Mon Aug 06, 2018 7:32 pm, edited 1 time in total.

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Z80 Protocol Decoder

Post by BigEd » Mon Aug 06, 2018 8:08 pm

Just for completeness: mine's an SGS Z8400BB1 Z80B CPU (6MHz) datecode 88346

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Z80 Protocol Decoder

Post by jgharston » Mon Aug 06, 2018 11:27 pm

Richard Russell wrote:
Mon Aug 06, 2018 6:25 pm
jgharston wrote:
Mon Aug 06, 2018 5:50 pm
RESET does nothing to them, which from power on will most likely be random contents, and at other times will be whatever they happened to have...
I think it's highly confusing to conflate 'reset' with 'power on'. By 'reset' I mean pulsing the reset pin of the chip, with no interruption of power.
Which is why I was consistantly refering to RESET, meaning a pulse of the RESET pin, and only mentioned power-on as an aside.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Z80 Protocol Decoder

Post by jgharston » Mon Aug 06, 2018 11:47 pm

hoglet wrote:
Mon Aug 06, 2018 7:31 pm
It's just my Z80 Decoder that is mis-predicting the F5/F3 flags when an LDIR is interrupted, but so far only in this specific case.
None of the flags should be changed by an interupt (unless the ISR messes with them). F is a full 8-bit register, every bit can hold a distinct state, it's not like the flags on the 6502 where a couple don't actually have a state and are always read as 1. PUSH BC:POP AF:PUSH AF:POP DE will copy C to E exactly for every value of C. In fact, the Spectrum 128 uses AF to hold a stacked return address for a short time.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
1024MAK
Posts: 8010
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Z80 Protocol Decoder

Post by 1024MAK » Mon Aug 06, 2018 11:48 pm

There are at least four variations in Z80 CPU cores (not including the various later versions that had deliberately extended, reduced or different official instructions):
  • Zilog NMOS and officially licensed manufacturer versions (for example Mostek, Synertek, SGS) - these should all be the same, as they are all based on the same chip design.
  • NEC versions - as colonel32 says, NEC reverse engineered the Z80, so NEC versions may have very minor differences in undocumented instructions or behaviour. But have no problems with the official Zilog instruction set and commonly used undocumented instructions.
  • Soviet and East European manufactured clones. Again, these were reverse engineered. I don't have a clue how compatible they are with regards to undocumented instructions or undocumented behaviour.
  • CMOS versions - unless anyone knows different, these should all be based on the same CMOS design. There are at least two differences compared to the Zilog NMOS version (Reference: https://faqwiki.zxnet.co.uk/wiki/Z80).
Mark
Last edited by 1024MAK on Mon Aug 06, 2018 11:50 pm, edited 1 time in total.

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Z80 Protocol Decoder

Post by hoglet » Wed Aug 08, 2018 7:08 pm

Thanks for info that Mark. I've managed to dig out a NEC D780 and the differences do seem minimal (i.e. it didn't raise any additional corner cases that I need to deal with in the decoder). The only difference in the Rak tests was the SCF/CCF and CCF/SFC tests give different results, as they do with the CMOS Z80. This has been previously reported here.

A couple of small updates from today....

1. I've improved the debug output, so that you see can the samples for a specific instruction immediately before that instruction.

Code: Select all

M1  FETCH 0 0 1 0 1 1 1 0 ff
M1  FETCH 0 0 1 0 1 1 1 0 ed
M1   NONE 1 1 1 0 1 1 1 0 ed
M1   NONE 1 1 1 1 1 1 1 0 ff
M1  FETCH 0 0 1 0 1 1 1 0 ff
M1  FETCH 0 0 1 0 1 1 1 0 71
M1   NONE 1 1 1 0 1 1 1 0 71
M1   NONE 1 1 1 1 1 1 1 0 ff
M1   NONE 1 1 1 1 1 1 1 0 ff
M2   IOWR 1 1 0 1 0 1 1 0 ff
M2   IOWR 1 1 0 1 0 1 1 0 ff
M2   NONE 1 1 1 1 1 1 1 0 ff : Wr=FF

828E : ED 71           : OUT (C),0            : 12/ 0 : A=AA F=SZ1H1VNC BC=00FE DE=DDEE HL=4411 IX=DD88 IY=FD77 SP=C000 : fail

M1  FETCH 0 0 1 0 1 1 1 0 ff
M1  FETCH 0 0 1 0 1 1 1 0 00
M1   NONE 1 1 1 0 1 1 1 0 62
M1   NONE 1 1 1 1 1 1 1 0 ff

8290 : 00              : NOP                  :  4/ 0 : A=AA F=SZ1H1VNC BC=00FE DE=DDEE HL=4411 IX=DD88 IY=FD77 SP=C000
The above is showing the "bug" in the CMOS Z80 where OUT (C),0 actually outputs 0xFF.

2. I've continued to investigate the flag issues I was seeing with LDI/LDD/LDIR/LDDR.

To recap, I was seeing the f5/f3 flags being set differently to the established wisdom (which is based on A + transfer data). I've narrowed this down to the following case: when an LDIR or LDDR operation is interrupted. i.e. it never happens with LDI/LDD, or with an LDIR/LDDR that completes normally (with BC=0).

I don't think this is a case of the interrupt somehow corrupting the flags (because, as JGH said earlier, interrupts don't generally have any effect on the flags). Rather, I think that when LDIR/LDDR is interrupted, the f5/f3 flags are set differently to when it completes normally. I have no idea on what basis they are set, so for now the decoder just marks them as undefined during the LDIR/LDDR to prevent false failures being flagged.

I've searched quite extensively, and I haven't ever seen this case documented. So I'm pretty sure ever emulator out there (including MAME) will diverge from what a real Z80 does. Which makes this case interesting for further investigation. It's been a few years I think since a new wrinkle on the Z80 behaviour was discovered.

Because it's dependent on an interrupt happening, writing a portable test-case for this is quite hard.

Dave

Coeus
Posts: 1080
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: Z80 Protocol Decoder

Post by Coeus » Wed Aug 08, 2018 7:58 pm

hoglet wrote:
Wed Aug 08, 2018 7:08 pm
To recap, I was seeing the f5/f3 flags being set differently to the established wisdom (which is based on A + transfer data). I've narrowed this down to the following case: when an LDIR or LDDR operation is interrupted. i.e. it never happens with LDI/LDD, or with an LDIR/LDDR that completes normally (with BC=0).
Dave, just thinking aloud here but I can't see any reason why LDIR would need to compute A+data for the documented affect of the instruction. I am therefore wondering if this happens by accident because the way it routes the data being transferred means it happens to be presented to the other ALU input, i.e. the one that is not A. While an interrupt may not have any effect on any documented registers might it do something with the ALU that presents some other value on its non-A input and this therefore drives those flags?

Does it make any difference which interrupt mode is in use?
Last edited by Coeus on Wed Aug 08, 2018 7:59 pm, edited 1 time in total.

Post Reply