A Little Help With A Z80

[hackling92]

Hello all this is my first post on the forums here, but I love to watch the series.  I am not the greatest when it comes to electronics but I love to play with them and learn how they work.

My question for everyone is, could someone upload a picture of what the mreq and rd lines are supposed to look like on a scope for a z80a.  I have a small prototype z80 i have been working on and the memory seems to be working but I get some really nasty wavefroms on those lines, so bad to the point it looks like there are 2-3 different ones overlapped.  From what I understand from the data sheet during the read cycle, both mreq and rd should go low and produce a single square wave.  On my z80 if I dont reset it after it comes up I get a perfect square wave but it obviously wont execute any code until it is reset.  After the reset though it begins to step through addresses and the waveform goes to hell again.  Also removing the wire from the rd line makes it look perfect after a reset, and will remain that way until the wire is re-installed and the chip is reset again.  As a side note the only chips connected at the moment are the z80 and the eeprom which is an at28c64b, there was a uart and some ram but after moving from the breadboard about a year ago I have been having issues so I am working through it part by part.

So like say im looking for a pic of those to lines if anyone has the time, or any tips are welcome also.

Thanks everyone 

[hackling92]

I was thinking I could be the pins tristating as I have read that they will do that on the z80 while the bus is leveling out.  I am just curious to see if someone could post a pic if they had the time to see how far off mine is, or if it is spot on.  But thanks for the comment.

[Skimask]

I don't think they (MREQ, RD, WR, etc) tri-state between cycles, just the address and data lines.

I'd be interested in seeing a picture of this circuit to see how badly that correlates to the ugliness of the signals.
Clock speed too high, V supply on the low side of the tolerances, long wires, loaded lines, etc.
A schematic of some sort would REALLY help ya know...

[hackling92]

Ill see what I can gather up tomorrow afternoon when I get a chance.  For a quick explanation  before I go to bed, the Z80 is on a breadboard at the moment with the at28c64b eeprom next to it with the data and address buses connected directly.  The wr line on the eeprom is tied high for the moment to eliminate it, and the output enable and chip enable are connected directly to the z80.  Also the clock is a 1 mhz oscillator I had sitting around, the signal from that looks pretty clean.  The leads on the board look terrible at the moment but are only about 5 inches long for the buses. Like say I will see if I can get some pictures tomorrow. 

[grumpydoc]

so bad to the point it looks like there are 2-3 different ones overlapped

Pretty normal appearance on an 'scope - the timing of the signals on these lines is dependant on what code is being run. Most micros are going to end up ion a loop doing a bit of processing and maybe checking for input so if that loop is several 10's instructions long you won't get a stable trigger because you're just going to trigger on one of the edges and it won't necessarily be the same point in the loop each time.

The "hold off" control on your 'scope might help.

Or you can put the CPU into a loop which is only a few instructions long, then you should be able to see the whole sequence. The shortest possible loop is a relative jump back to its own start address. The opcodes for that are "18 FE" IIRC

Or use a DSO in single shot mode to capture a run.

...the Z80 is on a breadboard at the moment with the at28c64b eeprom next to it with the data and address buses connected directly. 

Do you actually have it running any code at the moment?

[hackling92]

I had it running code but do to an early bug in my design my eeprom was erased.  I have tried it with and without code the waveform does not seem to change.

[grumpydoc]

I have tried it with and without code the waveform does not seem to change.

Write "18" at address 0 and "FE" at address 1. If the eeprom is correctly decoded at address 0000-1FFF then the CPU should just sit in a loop tight enough to watch on even the most basic 'scope - it should be 12 t-states long (so 12us with your 1MHz clock).

[PA0PBZ]

Not having any Z80's at hand but I remember seeing these waveforms on a scope and wondering myself how it could ever work, so what you are seeing is pretty normal.

[hackling92]

Ok as promised here are some pics.  But I must warn you my test setup was made in about ten minutes last week so it is pretty ugly.  Also the board it goes on was pretty much my first soldering project about a year ago so its not much better.  Sorry for the blur had to use my cellphone camera as my normal camera is not around at the moment

Waveform on MREQ after reset with RD hooked up

https://www.dropbox.com/s/qu0nn99dbjwjgos/20130422_152122.jpg



A close up

https://www.dropbox.com/s/06dtwu0esrvb3kk/20130422_152111.jpg



My test setup

https://www.dropbox.com/s/fvx98ye1auf2v9i/20130422_152135.jpg



And my revision 0 board.  Note: most of the chips are removed due to testing

https://www.dropbox.com/s/f55tnthw424o5k9/20130422_152145.jpg

[grumpydoc]

Waveform on MREQ after reset with RD hooked up

As far as it goes - yep that's what they look like.

Looking in more detail at your 'scope settings I see that you have the timebase set to .5 µs/div so the whole sweep is 5µs

The tightest loop you can write is going to take 10µs so you will need a sweep speed which takes more than 10µs to see much of interest. Otherwise you just see snippets of stuff all overlaid together - the 'scope just triggers on a rising edge but there's no guarantee that it will pick edges that correspond to the same instruction as the processor goes round a loop. If the processor is just executing random stuff you'll never have anything regular to lock to.

To have a chance of seeing a waveform which is stable on the 'scope:

Write an infinite loop at address 0 in the EEPROM - "18 FE" or "C3 00 00". The first takes 12 clock cycles to execute and the 2nd takes 10.

Hook channel 1 of the 'scope up to the clock and channel 2 to MREQ, set the timebase to 1µs/div, trigger on channel 2 negative and "alt" traces.

If using the relative jump loop (18 FE) use the sweep var control until 12 clock cycles are visible on the clock line. Otherwise 10.

You should be able to see a stable strace on the MREQ line.

Oh dear, I see I spent far too much time doing this as a teenager

[hackling92]

Thanks I have a tone of homework for college at the moment, but I will try my best to give that a shot tonight.

And by the way you can never spend too much time working on electronics. 

[hackling92]

Thanks grumpydoc that did the trick.  The line looks much better now.  Now to go back to the fun of setting my serial interface back up.  When its all done I will have to post some pics. 

[grumpydoc]

Thanks grumpydoc that did the trick.  The line looks much better now. 

Good.

To see more (i.e. a longer loop) set the main timebase slower and fiddle with the var sweep speed until it produces a clear trace and then use the x10 mag to stretch things out so that you can see the individual transitions. You can follow loops with perhaps 8-10 instructions this way which is enough to bit bang an interface and follow what's going on

If you choose which signal to trigger from carefully - M1 is good because that is active on the opcode reads - you can "walk" the other probe along several signals one at a time to build up a picture of what's happening.

If you get confident you can feed the trigger signal to the ext trigger and then look at two other signals together.

Look at the signatures of the two loops on the 'scope - they look different - one will give you M1/MREQ, MREQ, MREQ fairly evenly (4, 3 and 3 clocks apart). The other will give you M1/MREQ, MREQ,<pause> with the pause being the bit where the CPU calculates the destination of the jump.

You now have a debugging tool - you can do a test and get the CPU to jump to one of those loops. Since they look different on the 'scope you can tell which way the test went.

It's worth adding a single, simple 8-bit output port to you hardware design - just an octal latch and some address decoding. This won't need any complex set-up like the peripheral chips do you can just output bytes to it. You can then use that to generate triggers for the 'scope or light LEDs for debugging.

Z80 tip of the day:

If you look at the data sheet you will see that the OUT (C), A instruction is really OUT (BC), A so the Z80 has 64k of I/O space if you fully decode the address bus. If you want, this can be used to add an extra 64k of RAM.

[ignator]

hackling92; if your dealing with a signal integrity problem, you need fractional nanosecond (0 to 3000 picoseconds maybe a little slower) edge rates. You indicate 1MHz processor clock, but what is the speed rating of the processor? As this indicates the output drivers edge rate relative to the component specification.  Biggest problem is the inductance of your control connections, as the fast edge rate (dv/dt) results in a fast current pulse (di/dt), this charges this inductance, and via lenz's law, the charged energy in this inductor, which will be injected back on the line, as the output driver completes it's edge transition (a major misnomer is to call these reflected pulses, but that indeed with what the whole electronics field calls them, this just causes confusion, like "imaginary" numbers).

Ill see what I can gather up tomorrow afternoon when I get a chance.  For a quick explanation  before I go to bed, the Z80 is on a breadboard at the moment with the at28c64b eeprom next to it with the data and address buses connected directly.  The wr line on the eeprom is tied high for the moment to eliminate it, and the output enable and chip enable are connected directly to the z80.  Also the clock is a 1 mhz oscillator I had sitting around, the signal from that looks pretty clean.  The leads on the board look terrible at the moment but are only about 5 inches long for the buses. Like say I will see if I can get some pictures tomorrow.