Z80 Protocol Decoder

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
leenew
Posts: 4022
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire
Contact:

Re: Z80 Protocol Decoder

Post by leenew » Wed Aug 22, 2018 10:44 pm

Aha!
Obvious really!
My applause was warranted.
Have another =D>

Lee.

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Wed Aug 22, 2018 10:57 pm

The Z80 atom has been split. 8)

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Wed Aug 22, 2018 11:23 pm

A special quiz:

Code: Select all

0000:	JP (IY)
...
TEST:	XOR A
	LD IY,RESUME
	OUT (159),A		;/RESET pulse 4T after OUT
	HALT
	INC A
	DEC A
RESUME:	DEC A			;A = ??
Tested and works as expected.

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

Re: Z80 Protocol Decoder

Post by hoglet » Thu Aug 23, 2018 8:04 am

TonyB wrote:
Wed Aug 22, 2018 11:23 pm
A special quiz:

Code: Select all

0000:	JP (IY)
...
TEST:	XOR A
	LD IY,RESUME
	OUT (159),A		;/RESET pulse 4T after OUT
	HALT
	INC A
	DEC A
RESUME:	DEC A			;A = ??
Tested and works as expected.
My educated guess would the A=00?

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

Re: Z80 Protocol Decoder

Post by hoglet » Thu Aug 23, 2018 9:44 am

And the reasoning for my guess of A=00 is your excellent article describing special reset:
If a special reset pulse occurs when HALT is low the halt state is exited immediately and the opcode of the instruction after HALT will be fetched and executed with no delay. This is possible because special reset is sampled on the rising edge of M1T2 and the opcode is sampled on the rising edge of M1T3. (Tests show that HALT goes high after the falling edge of M1T2.) Once the instruction after HALT is completed there is an opcode fetch of the next instruction then a fetch from address zero as already described.
http://www.primrosebank.net/computers/z ... _reset.htm

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Thu Aug 23, 2018 12:44 pm

hoglet wrote:
Thu Aug 23, 2018 8:04 am
TonyB wrote:
Wed Aug 22, 2018 11:23 pm
A special quiz:

Code: Select all

0000:	JP (IY)
...
TEST:	XOR A
	LD IY,RESUME
	OUT (159),A		;/RESET pulse 4T after OUT
	HALT
	INC A
	DEC A
RESUME:	DEC A			;A = ??
Tested and works as expected.
My educated guess would the A=00?
Yes, A = 00 for Special Reset, A = FF for normal reset. I mentioned this because Special Reset is working on my device perfectly but Bus Request + Reset is not. The opcode at address 0 is being read incorrectly quite often or all of the time after the reset, probably due to the reset pulse being too short.

The following occurred during previous Special Reset tests:

Code: Select all

3T reset pulse, low at rising edges of M1T4 & M1T1 & M1T2
N.B. /MREQ low during M1T1 of opcode fetch from address 0000

	:   M1 (NOP)    :   M1 (NOP)    :   M1 (PC=0)   :
	:T1  T2  T3  T4 :T1  T2  T3  T4 : T1 T2  T3  T4 :
	:_   _   _   _  :_   _   _*  _* :_*  _   _   _  :
 CLK	| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_|
	:__________     :       ________________________:
/RESET	:          |___________|        :               :
	:__       _     :__       _____ :         _     :
/MREQ   : 1|__0__|1|__0|: 1|__0__|1   1|:_0___0__|1|__0|:
        : _______       : ______________:________       :
/RFSH   :|1   1  |0___0_:|1   1   1   1 : 1   1  |0___0_:

Pardon the ASCII graphics. /MREQ and /RFSH were sampled on falling edge of CLK and * means one or both of these differ from the normal M1 cycle. Note /MREQ is low at start of opcode fetch from 0 and could be low before PC is on the address bus. I think the anomaly then was because /RESET is low 5T earlier at rising edge of M1T4.

We are having similar problems with /BUSREQ during M1, M2 or M3. I'm hoping that this problem can be solved by making the reset pulse longer. What I don't know is what M and T are when /BUSACK is low. If /BUSREQ is low at rising edge of M1T4, for example, will they stay like that or will they move on to M2T1 (if the instruction has a M2) or M1T1?
Last edited by TonyB on Thu Aug 23, 2018 9:00 pm, edited 3 times in total.

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

Re: Z80 Protocol Decoder

Post by jgharston » Thu Aug 23, 2018 8:46 pm

Wow! Well done! \:D/

Code: Select all

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

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

Re: Z80 Protocol Decoder

Post by BigEd » Thu Aug 23, 2018 8:52 pm

An excellent result, and commendably rapid progress from idea to implementation!

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Thu Aug 23, 2018 9:43 pm

Increasing the /RESET pulse after /BUSREQ and /BUSACK from 1T to 8T seems to have solved the problems we were having with bad reads from address 0000, which were worse for a CMOS CPU than a NMOS.

We've all heard of single-stepping. Well, depending on the instruction, my Bus Request Reset device can do single-stepping* and half-, third-, quarter-, fifth- and sixth-stepping as well! :D

The stepping is always from the start of the instruction and the code to control it is simple:

Code: Select all

OUT (n),A	;Load counter with address A(4:0) for specific M cycle
JP nn		;Jump to instruction
On second thoughts no need to jump at all:

Code: Select all

OUT (n),A	;Load counter with address A(4:0) for specific M cycle
xxx		;Copy of instruction
* Bus Request Reset does almost but not quite single-stepping which is very handy for branch instructions especially conditional ones as any branch happens after the instruction and the new PC can be deduced from WZ (and the opcode and flags if necessary).
Last edited by TonyB on Fri Aug 24, 2018 1:45 am, edited 5 times in total.

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Fri Aug 24, 2018 4:54 pm

Here are a couple of photos of the new gadget in a Memotech MTX512:

Image

Image

From bottom to top in side view:

1. Z80 CPU socket soldered to motherboard.
2. Socket to raise height to avoid Z80 CTC.
3. Prototype board with socket strips on top.
4. Socket to protect CPU when swapping in and out.

A PCB version would have the GAL underneath the CPU and extra socket 4 should provide enough clearance for this with socket 2 not required. The footprint of the PCB would be a little bit wider than a 40-pin socket.

Is the best offset for the CPU the way it is now as seen in the top view? Cover the GAL with your hand to get an idea of how the final product would look. The gap between the bottom of the CPU and the edge of the PCB would be much less than in the prototype.

Many thanks to Dave Stevenson for the device assembly & testing and for the photos. There is a lot of info about Memotech computers on Dave's website:
http://www.primrosebank.net/computers/mtx/mtx512.htm

I hope there will be a PCB version but it depends on the interest from others. Regarding how it works, there is no point using Bus Request + Reset to examine the last machine cycle of instructions (except for the block repeat instructions). Special Reset could be used instead, preserving the I and R registers and interrupt state.

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Fri Aug 24, 2018 5:47 pm

It's great that we can read the Z80 WZ register but it is must be the slowest register to read ever. I've had a final (?) go at the code and it is now running successfully three times faster than before. The huge speed increase comes from replacing the CPD that decrements WZ with a block of 25 CPDs before testing whether bit 13 has flipped. If it has not, then do 25 more decrements, etc. If it has, increment with a CPI until bit 13 flips back.

N.B. LOOP1 and LOOP2 must be in the same page.

Code: Select all

WZRDFAST:
	DI
	LD A,(0000)		;Instruction under test
;
	LD D,20H
	BIT 0,(HL)
	PUSH AF
	POP BC
	LD A,C
	AND D
	LD E,A			;Save WZ[13]
	LD HL,-1
	LD IX,LOOP1
LOOP1:
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	CPD
	BIT 0,(HL)
	PUSH AF
	POP BC
	LD A,C
	AND D
	XOR E			;A = 20H if bit 13 flipped, else 0
	ADD A,A	
	DB 0DDH
	ADD A,L			;ADD A,IXL
	DB 0DDH
	LD L,A			;LD IXL,A
	JP (IX)			;Jump to LOOP2 if bit 13 flipped, else to LOOP1
LOOP2:
	CPI
	BIT 0,(HL)
	PUSH AF
	POP BC
	LD A,C
	AND D
	XOR E
	JR Z,EXIT		;Exit if bit 13 flipped back
	JP (IX)
EXIT:				;HL = /WZ[12:0], so /HL = WZ[12:0]
	LD A,H
	CPL
	OR E			;Add WZ[13]
	LD H,A
	LD A,L
	CPL
	LD L,A
	RET			;HL = WZ[13:0], A = WZ[7:0]
Last edited by TonyB on Sun Aug 26, 2018 1:02 pm, edited 7 times in total.

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Thu Aug 30, 2018 1:10 pm

Interesting result from my device. Before the test all flags were cleared using XOR A then INC A. Bus request + reset occurred at the end of the M cycles shown below, following which code at address 0000 recorded the register values. Gap between Mx and A= shows any flags that are set.

Code: Select all

0222   ADC HL,DE       M1          A=00 BC=0000 DE=7FFF HL=8001 SP=3FFE WZ=0000
0222   ADC HL,DE       M2          A=00 BC=0000 DE=7FFF HL=8001 SP=3FFE WZ=0000
0222   ADC HL,DE       M3          A=00 BC=0000 DE=7FFF HL=8000 SP=3FFE WZ=0000
0222   ADC HL,DE       M4          A=00 BC=0000 DE=7FFF HL=0000 SP=3FFE WZ=0000
The first two M cycles in ADC HL,DE are opcode fetches and the registers have their unchanged entry values. 'ADC L,E' is done in M3 and 'ADC H,D' in M4.

The results were the same for NMOS and CMOS Z80s. As a check, the test was re-run with A=11 on a NMOS CPU, which confirms that reset does not zero AF.

Code: Select all

0222   ADC HL,DE       M1          A=11 BC=0000 DE=7FFF HL=8001 SP=3FFE WZ=0000
0222   ADC HL,DE       M2          A=11 BC=0000 DE=7FFF HL=8001 SP=3FFE WZ=0000
0222   ADC HL,DE       M3          A=11 BC=0000 DE=7FFF HL=8000 SP=3FFE WZ=0000
0222   ADC HL,DE       M4          A=11 BC=0000 DE=7FFF HL=0000 SP=3FFE WZ=0000
Here is the last line when hardware is not present and emulated by JP 0 after ADC HL,DE.

Code: Select all

0222   ADC HL,DE       M4  Z H   C A=11 BC=0000 DE=7FFF HL=0000 SP=3FFE WZ=0000

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Sun Sep 09, 2018 3:57 pm

I'd like a PCB version of my device to work with pretty much any Z80 system with a socketed CPU. The Acorn Z80 Co Pro board has two non-standard features: (1) /BUSREQ is tied directly to +5V and (2) the Tube chip hogs the entire I/O address space.

(1) is easily solved by connecting the GAL /BUSREQ output only to the CPU and to solve (2) I'm looking at using refresh addresses to program the device, via register R, instead of I/O addresses. Does anyone know whether any Acorn software sets bit 7 of R? I've looked at the ROM code and there are no LD R,A instructions. It doesn't matter if some games do but I hope that important things such as CP/M do not.

The Z80 Protocol Decoder hardware might be able test for this automatically with a modification to sample A7 when /MREQ is low and both /RD and /WR are high. When investigating the Special Reset we tested whether R is incremented before or after being placed on the address bus. The result was conclusive but I've forgotten it and I can't find it anymore. If both A7 and A6 were sampled then the following code would provide the answer:

Code: Select all

	XOR A
	LD R,A			;Ensure bit 7 = 0
	DEC A
	LD R,A
	NOP			;What is A6 during the NOP refresh?
R will be set to FF during opcode fetch of NOP, due to execute/fetch overlap. If A(7:6) = 11 then R is post-incremented, if A(7:6) = 10 then R is pre-incremented.

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

Re: Z80 Protocol Decoder

Post by hoglet » Sun Sep 09, 2018 4:15 pm

Tony,
TonyB wrote:
Sun Sep 09, 2018 3:57 pm
I'd like a PCB version of my device to work with pretty much any Z80 system with a socketed CPU. The Acorn Z80 Co Pro board has two non-standard features: (1) /BUSREQ is tied directly to +5V and (2) the Tube chip hogs the entire I/O address space.
Is your device write only?

Although the tube occupies the entire address space, even addresses (A0=0) are only ever read from on the parasite:
http://www.sprow.co.uk/bbc/hardware/arm ... df#page=14
(look at the right half on page 14, labelled parasite)

So I think if you mapped your device to an even address (or made it configurable with jumpers) then it would work fine.

Dave

TonyB
Posts: 60
Joined: Sat Aug 11, 2018 6:45 pm
Contact:

Re: Z80 Protocol Decoder

Post by TonyB » Sun Sep 09, 2018 7:34 pm

hoglet wrote:
Sun Sep 09, 2018 4:15 pm
Tony,
TonyB wrote:
Sun Sep 09, 2018 3:57 pm
I'd like a PCB version of my device to work with pretty much any Z80 system with a socketed CPU. The Acorn Z80 Co Pro board has two non-standard features: (1) /BUSREQ is tied directly to +5V and (2) the Tube chip hogs the entire I/O address space.
Is your device write only?

Although the tube occupies the entire address space, even addresses (A0=0) are only ever read from on the parasite:
http://www.sprow.co.uk/bbc/hardware/arm ... df#page=14
(look at the right half on page 14, labelled parasite)

So I think if you mapped your device to an even address (or made it configurable with jumpers) then it would work fine.

Dave
Thanks for the reply and info, Dave. I think OUTs and INs on even addresses would work for the Acorn board, which means it would not require special treatment as isolating /BUSREQ is needed for at least one other Z80 system. Using /IORQ and /M1 to decode I/O saves one of the ten GAL macrocells compared to /IORQ and /WR. In its PCB incarnation the only Z80 signals that will not be connected to the GAL are D0-D7, A8-A15 and /RFSH. The latter can be derived from /M1, which is how the Z80 itself generates the refresh signal.

Testing of bus request + reset is progressing at a very leisurely pace. The results I posted on August 30th show that the reset stops the flags from being written back to F and the same might apply to A. What if anything happens when the Z80 gives up the bus is an interesting question. For the ADC HL,DE instruction, there is no time for L := L + E + CF entirely within M3, so is it done (a) immediately after M3 when /BUSACK is low or (b) during M4 after /BUSACK has gone high?

My device can test post- or pre-increment of R.

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Wed Jan 22, 2020 12:41 pm

These are the signals that must be captured, correct?:

- Data 1 - 8
- /M1
- /MREQ
- /IORQ
- /RD
- /WR
- /RST

For the file to be properly decoded, must these signals be capture in a specific order? I.e. Probe-1 on the logic analyzer must be a specific signal, etc? And must they be named in a specific way?

I.e. How do I set up the Logic Analyzer to create a correctly formatted file for the Z80 Decoder?

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

Re: Z80 Protocol Decoder

Post by hoglet » Wed Jan 22, 2020 1:23 pm

JannievanZyl wrote:
Wed Jan 22, 2020 12:41 pm
These are the signals that must be captured, correct?:

- Data 1 - 8
- /M1
- /MREQ
- /IORQ
- /RD
- /WR
- /RST

For the file to be properly decoded, must these signals be capture in a specific order? I.e. Probe-1 on the logic analyzer must be a specific signal, etc? And must they be named in a specific way?

I.e. How do I set up the Logic Analyzer to create a correctly formatted file for the Z80 Decoder?
The default mapping assumed by the z80 decoder is:

Code: Select all

   D0 -> Logic Analyzer Bit 0 
   D1 -> Logic Analyzer Bit 1 
   D2 -> Logic Analyzer Bit 2 
   D3 -> Logic Analyzer Bit 3 
   D4 -> Logic Analyzer Bit 4 
   D5 -> Logic Analyzer Bit 5 
   D6 -> Logic Analyzer Bit 6 
   D7 -> Logic Analyzer Bit 7 
  /M1 -> Logic Analyzer Bit 8 
  /RD -> Logic Analyzer Bit 9 
  /WR -> Logic Analyzer Bit 10 
/MREQ -> Logic Analyzer Bit 11 
/IORQ -> Logic Analyzer Bit 12 
/WAIT -> Logic Analyzer Bit 13 
 /RST -> Logic Analyzer Bit 14
There are command line options to change these, but I would recommend using the default, as it makes exchanging files easier.

(WAIT is only really needed to get accurate cycle counts)

If you are using synchronous capture mode, the use the rising edge of CLK to take a sample, and include the --phi= argument (with no number) on the decoder command line.

If you are using asynchronous capture mode, this needs to be at least 5x the system clock rate, ideally 10x. In this case, connect CLK to Logic Analyzer Bit 15.

What model of Logic Analyzer are you using?

Dave

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Wed Jan 22, 2020 2:37 pm

Dave,

I'm using the Kingst LA1010. It can capture 16 channels @ 16MHz

http://www.qdkingst.com/en/products

Something I've noticed is that there seems to be xtalk between the different channels, especially if you have many connected up. I was wondering if it is a function of the unshielded cables.

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

Re: Z80 Protocol Decoder

Post by hoglet » Wed Jan 22, 2020 3:02 pm

JannievanZyl wrote:
Wed Jan 22, 2020 2:37 pm
I'm using the Kingst LA1010. It can capture 16 channels @ 16MHz
OK, so you'll be using asynchronous mode, in which case you need to connect the CLK signal to Bit 15.

What speed is your Z80 running at?
JannievanZyl wrote:
Wed Jan 22, 2020 2:37 pm
Something I've noticed is that there seems to be xtalk between the different channels, especially if you have many connected up. I was wondering if it is a function of the unshielded cables.
It will be worse with:
- unshielded cables
- longer cables
- faster edges of modern TTL families
- multiple signals changing at the same time

That said, I haven't seen any decoding failures yet that I have put down to crosstalk.

Dave

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Wed Jan 22, 2020 5:30 pm

hoglet wrote:
Wed Jan 22, 2020 3:02 pm
OK, so you'll be using asynchronous mode, in which case you need to connect the CLK signal to Bit 15.
Cool, tx!
hoglet wrote:
Wed Jan 22, 2020 3:02 pm
What speed is your Z80 running at?
The system I need to debug is running at 3.58MHz, a Spectravideo SV-328

BTW, is there a description of the command-line options somewhere?

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

Re: Z80 Protocol Decoder

Post by hoglet » Wed Jan 22, 2020 6:06 pm

JannievanZyl wrote:
Wed Jan 22, 2020 5:30 pm
The system I need to debug is running at 3.58MHz, a Spectravideo SV-328
You'll likely need to capture at 16MHz then.
JannievanZyl wrote:
Wed Jan 22, 2020 5:30 pm
BTW, is there a description of the command-line options somewhere?
Here is a bit of built in help:

Code: Select all

./decodez80 --help
Usage: decodez80 [OPTION...] [FILENAME]
The following options control the mapping of logic analyzer bits to signals:

Code: Select all

      --data=BITNUM          The start bit number for data
      --iorq[=BITNUM]        The bit number for iorq
      --m1[=BITNUM]          The bit number for m1
      --mreq[=BITNUM]        The bit number for mreq
      --phi[=BITNUM]         The bit number for phi
      --rd[=BITNUM]          The bit number for rd
      --rst[=BITNUM]         The bit number for rst
      --wait[=BITNUM]        The bit number for wait
      --wr[=BITNUM]          The bit number for wr
If BITNUM is omitted, that means the signal is unconnected.

The following options control what's included in the output.

Code: Select all

  -a, --address              Show address of instruction.
  -h, --hex                  Show hex bytes of instruction.
  -i, --instruction          Show instruction.
  -s, --state[=LEVEL]        Show register/flag state.
  -y, --cycles               Show number of bus cycles.
  -d, --debug=LEVEL          Sets debug level (0 1 or 2)
I typically include all of these, apart from d.

LEVEL is 0, 1 or 2.

The following sets the CPU type:

Code: Select all

  -c, --cpu=CPU              Enable cpu specific behaviour
CPU is one of:

Code: Select all

   default
   nmos_zilog
   nmos_nec
   cmos
Using this is rarely necessary, it affects emulating some undocumented aspects of a few instructions:
- SCF
- CCF
- OUT (C),0

The following sets the defauly interrupt mode:

Code: Select all

      --im=MODE              The default interrupt mode
MODE is 0, 1 or 2.

This is useful if you need to start capturing after the interrupt mode has been set.

And the following are help/version related.

Code: Select all

  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version
This session is very useful for me - I'll go back through this thread and turn some of this into getting started documention on the Wiki. So please keep asking if things are not clear.

Dave

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Wed Jan 22, 2020 6:15 pm

hoglet wrote:
Wed Jan 22, 2020 6:06 pm
This session is very useful for me - I'll go back through this thread and turn some of this into getting started documention on the Wiki. So please keep asking if things are not clear.

Dave
Thanks Dave,

This is a seriously impressive bit of work you - and the other members here - pulled off!

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Thu Jan 23, 2020 6:20 pm


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

Re: Z80 Protocol Decoder

Post by hoglet » Thu Jan 23, 2020 9:21 pm

JannievanZyl wrote:
Thu Jan 23, 2020 6:20 pm
You seen this?;

https://sigrok.org/wiki/Protocol_decoder:Z80
Yes, and indeed this was what made me realise that this kind of instruction stream decoding might be possible for the 6502.

The 6502 Decoder started life as a sigrok protocol decoder as well (written in Python), but it turned out to be way too slow / memory inefficienty for the volume of data I wanted to be able to process. Moving from Python to C improved things by two orders of magnitude (i.e, ~100x).

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Sat Jan 25, 2020 6:36 pm

I ran the first few logs of the Z80 boot sequence but getting some unexpected results.

1. There are a number of errors before the Reset is assumed.
2. Then, the 3F at Addr 0000 is not there in the actual code, rather the first instruction is the JP 7B50h which is decoded as at Addr 0001 but is actually at Addr 0000.
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: unexpected transition from MEMWR to FETCH
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: unexpected transition from FETCH to MEMWR
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: Incorrect cycle type for prefix/opcode: NONE
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for prefix/opcode: MEMWR
WARNING: Incorrect cycle type for write op1: FETCH
INFO: RESET inferred
0000 : 3F : CCF : 60781/ 8 : A=FF F=SZ?H?V BC=???? DE=???? HL=???? IX=???? IY=???? SP=FFFF
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
WARNING: Incorrect cycle type for immediate1: FETCH
0001 : C3 50 7B : JP 7B50h : 229/39 : A=FF F=SZ?H?V BC=???? DE=???? HL=???? IX=???? IY=???? SP=FFFF
7B50 : F3 : DI : 5/ 1 : A=FF F=SZ?H?V BC=???? DE=???? HL=???? IX=???? IY=???? SP=FFFF
7B51 : 31 F6 F4 : LD SP,F4F6h : 11/ 1 : A=FF F=SZ?H?V BC=???? DE=???? HL=???? IX=???? IY=???? SP=F4F6
7B54 : 21 00 00 : LD HL,0000h : 11/ 1 : A=FF F=SZ?H?V BC=???? DE=???? HL=0000 IX=???? IY=???? SP=F4F6
7B57 : 2B : DEC HL : 7/ 1 : A=FF F=SZ?H?V BC=???? DE=???? HL=FFFF IX=???? IY=???? SP=F4F6
7B58 : 7C : LD A,H : 5/ 1 : A=FF F=SZ?H?V BC=???? DE=???? HL=FFFF IX=???? IY=???? SP=F4F6
7B59 : B5 : OR L : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFFF IX=???? IY=???? SP=F4F6
Deeper into the decode, I again get errors.
7B58 : 7C : LD A,H : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDC IX=???? IY=???? SP=F4F6
7B59 : B5 : OR L : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDC IX=???? IY=???? SP=F4F6
7B5A : 20 FB : JR NZ,7B57h : 13/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDC IX=???? IY=???? SP=F4F6
7B57 : 2B : DEC HL : 7/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
7B58 : 7C : LD A,H : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
WARNING: unexpected transition from FETCH to MEMRD
7B59 : B5 : OR L : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
7B5A : 20 FB : JR NZ,7B57h : 13/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
WARNING: Incorrect cycle type for prefix/opcode: MEMRD
WARNING: Incorrect cycle type for prefix/opcode: MEMRD
7B57 : 7C : LD A,H : 12/ 2 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
7B58 : B5 : OR L : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
7B59 : 20 FB : JR NZ,7B56h : 13/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDB IX=???? IY=???? SP=F4F6
7B56 : 2B : DEC HL : 7/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDA IX=???? IY=???? SP=F4F6
7B57 : 7C : LD A,H : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDA IX=???? IY=???? SP=F4F6
7B58 : B5 : OR L : 5/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDA IX=???? IY=???? SP=F4F6
7B59 : 20 FB : JR NZ,7B56h : 13/ 1 : A=FF F=S Y XV BC=???? DE=???? HL=FFDA IX=???? IY=???? SP=F4F6
I *think* this might be caused by a flaky /RESET signal and then by spurious spikes in the other signals. See post below for pics.
Last edited by JannievanZyl on Sat Jan 25, 2020 7:28 pm, edited 2 times in total.

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Sat Jan 25, 2020 6:48 pm

You can see here that the /RESET line seems to bounce all over the show before it stabilizes
Z80-reset.png
And here you can see spurious spikes, which I suspect are an artifact created by the logic analyser.
Z80-spikes.png
Could these be the reason behind the errors in the decoded file?
Last edited by JannievanZyl on Sat Jan 25, 2020 7:28 pm, edited 1 time in total.

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

Re: Z80 Protocol Decoder

Post by hoglet » Sat Jan 25, 2020 6:56 pm

JannievanZyl wrote:
Sat Jan 25, 2020 6:48 pm
You can see here that the /RESET line seems to bounce all over the show before it stabilizes
I have also seen example of RESET looking like this. It's what you get if there is a really slow rising edge (from a large RC) that buffered by a none-schmitt buffer.
JannievanZyl wrote:
Sat Jan 25, 2020 6:48 pm
And here you can see spurious spike, which I suspect are an artifact created by the logic analyser.

Could these be the reason behind the errors in the decoded file?
It's hard to tell, it depends on when the glitch is happeneing wrt RD and WR. You would need to zoom in on just one of then.

Could you ZIP and upload a sample capture file so I can have a play? (Or copy one to somewhere like dropbox)

Dave

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Sat Jan 25, 2020 7:07 pm

hoglet wrote:
Sat Jan 25, 2020 6:56 pm
Could you ZIP and upload a sample capture file so I can have a play? (Or copy one to somewhere like dropbox)
Dave
Was hoping you would ask! :)

I'll send you the dropbox links.
Last edited by JannievanZyl on Sat Jan 25, 2020 7:26 pm, edited 1 time in total.

JannievanZyl
Posts: 213
Joined: Sat Feb 11, 2017 8:56 pm
Location: Cape Town, South Africa
Contact:

Re: Z80 Protocol Decoder

Post by JannievanZyl » Sat Jan 25, 2020 7:18 pm

hoglet wrote:
Sat Jan 25, 2020 6:56 pm
I have also seen example of RESET looking like this. It's what you get if there is a really slow rising edge (from a large RC) that buffered by a none-schmitt buffer.
Yup, they just use a few inverters. I seriously considered putting a Schmitt gate in there to clean it up. :)

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

Re: Z80 Protocol Decoder

Post by hoglet » Sat Jan 25, 2020 7:47 pm

JannievanZyl wrote:
Sat Jan 25, 2020 7:07 pm
hoglet wrote:
Sat Jan 25, 2020 6:56 pm
Could you ZIP and upload a sample capture file so I can have a play? (Or copy one to somewhere like dropbox)
Dave
Was hoping you would ask! :)

I'll send you the dropbox links.
What would also be useful would be some kind of disassembly (or assembler listing) for the code being executed on RESET.

Dave

Post Reply