Grant Searle Z80 SBC troubleshooting

[255]

Here is a closer look at address 0 after reset. What does this overwritten waveform entail, does it mean there is a possibility of a short, or is it something to do with the tristate logic ?

[MK14]

That waveform looks ok, as regards, faults.

In the top left hand corner of your scope, you seem to have a 0.1V cal probe connection point. I'm hoping it's around a 1KHz square wave test signal, for calibrating your probes (no manual on your scope, so I can't check this). You can make sure that the square waves look straight. If not, you may need to adjust the probes trim.

explanation here:
https://www.picotech.com/library/application-note/how-to-tune-x10-oscilloscope-probes

It makes the waveforms, nice and sharp, for better results when doing this type of work.

You just connect the probe to the test point, if it looks a nice SQUARE waveform, fine. If not, there is usually a tiny adjuster at the end of your scope probe which can be turned (ideally with a plastic tool, to avoid metal interfering with the settings).

It is somewhat important. Otherwise you don't know if the slopes are just the scope probes being out of adjustment, or the signals really are like that.

[MK14]

Here is a closer look at address 0 after reset. What does this overwritten waveform entail, does it mean there is a possibility of a short, or is it something to do with the tristate logic ?

The OVERWRITTEN aspect of it is fine, as far as I can tell. It is because you are using a non-storage scope, so it merges lots of traces into the same place. Hence why it looks funny.

I'd suggest you use a non-storage scope, just for cursory checks, to look for dramatic faults, such as always low, always high or "funny" due to short circuits between pins (difficult to describe, it moves between the low and high levels, in a haphazard way, and should be distinguished from tri-stating. Tri-stating can be checked by looking at the control signals, to make sure the bus is suppose to be valid at that time, but is probably tricky to do with a non-storage scope).

More complicated fault analysis, ideally needs a proper digital storage scope. Which shows a fast, single shot, "picture/photgraph" of the digital signals. Rather than showing lots of repeated waveforms, on the same parts of the screen (non-storage).

A long time ago, non-storage scopes were used for complicated fault finding. Clever techniques (complicated triggering, making the signal repeat on purpose and stuff) and usage allowed this. These days, it is best to go for a digital storage scope.                                                         

[Ian.M]

The old-skool tricks that let you do serious debugging with a two channel non-storage delay timebase CRO were mostly based on making the CPU repeat a short sequence of instructions and generating ONE trigger pulse at a point within that sequence fed to the Ext trigger input.   That meant that the scope trace X coordinate was locked to the instruction sequence timing, so you could probe a pair of signals, trace them onto tracing paper, then probe another two and repeat until you had all the signals you needed recorded on the paper, with correct relative timing.  Nowadays, you'd photo them with a digital camera on a mount attached to the scope or from a mini-tripod so all the pictures are from exactly the same angle and distance.

Once you've set up a repetitive signal with stable triggering, the B timebase can be used for zooming in on a particular part of it.   If you press the A INTENS button, it will use the B timebase for the sweep, and if the A timebase is set faster (lower time/div) it will bright up the trace, for a region controlled by the A timebase setting and the DELAY TIME POSITION knob just above the Ext input.  Press the B button and the intensified region expands to the full width of the screen.

For the triggering from a particular logic pattern, one would typically use two banks of DIP switches, some magnitude comparators and pullup resistors on all the comparator inputs.   One bank of switches would ground each bit individually of one set of the comparator data inputs, so switch open = '1' and switch closed = '0'.  The other bank of switches would go between the signals being monitored for the logic pattern and the other set of comparator data inputs, so switch closed = active and switch open = Don't Care.  With enough comparotors, switches etc. that would let you generate a trigger pulse on any single memory or I/O access.

However all the above is useless if you cant get the instructions to repeat  fast enough to get a bright enough scope trace to read.  If you were pushing the limits of trying to view a rare event, you'd have to darken the room to see the faint trace.

Nowadays, you'd stop faffing around with custom triggering a lot sooner than that, and just use it to establish that all the memory chips and I/O chips can be accessed with acceptable timing.   One trick that can be used is to burn an EEPROM with an instruction sequence terminated by HALT.   When it reaches the HALT, the Z80's /HALT pin will go low, and if its arranged to pull /RESET low once /HALT has been asserted for a short time, the CPU will reset and repeat the instruction sequence.  You can then trigger the scope on the rising edge of /RESET.

Once you've got it basically accessing all the memory and I/O chips with acceptable timing, further troubleshooting is best done with a cheap logic analyser.   

[NivagSwerdna]

From the earlier pictures of the board itself I get bad vibrations from the layout.  The X1 should be geographically very close to C6 and C7 (can't even see them) and the X1/C6/C7 combo very close to U5 pins 1 and 2.

Maybe you should tidy up your X1/C6/C7/U5/R3  combo to be close before moving on.

[255]

NivagSwerdna,

I think you misunderstand the board layout. Instead of a crystal, I used an oscillator which does not require C6 and C7. All those little 100nF caps you see on the board are local decoupling caps for the main chips. Sorry for not stating that earlier.

[NivagSwerdna]

I don't have a datasheet of that device... XO-055BAT?  But you are using that directly as your clock?

[255]

Yes, the oscillator is being used a clock source for the Z80 and the ACIA. Coincidentally, I think the oscillator may be the component causing the issues so I have a 3.6864 MHz oscillator arriving in the mail.

[NivagSwerdna]

The Z80 datasheets suggest that it should be receiving a TTL level Square Wave with 50/50 duty cycle... I'm not sure that is what you are supplying.
The original design used U5 to achieve this.  I'm not sure I can help any further without a schematic of your design.

[255]

I just realized that my oscillator operates on a 3.3V supply, not 5V.  That's probably why my clock signal looks so bad. Anyway, that issue will be resolved when my 3.6864Mhz , 5V, oscillator arrives.

[glarsson]

At least the Z80 chips made 40 years ago was quite picky about the clock. Looking at Z80 designs you often found some extra components driving the clock input, not just a ordinary TTL gate. Only 3.3V was out of the question.

[NivagSwerdna]

I just realized that my oscillator operates on a 3.3V supply, not 5V.  That's probably why my clock signal looks so bad. Anyway, that issue will be resolved when my 3.6864Mhz , 5V, oscillator arrives.

I would be worrying more about what it outputs... both in terms of shape and drive.  It needs to be able to drive TTL and really it needs to be square!  Good luck!

[NivagSwerdna]

Incidentally, here is an example from years gone by... the pattern is very common... two gates in a 04 and in this case the clock is used in multiple locations in the circuit with a divide by 4 for the Z80A

[glarsson]

Yes, a beefy bus driver (74LS367) and a low value pull up resistor. That's what it takes to drive the Z80 clock.

[NivagSwerdna]

Yes, a beefy bus driver (74LS367) and a low value pull up resistor. That's what it takes to drive the Z80 clock.

Indeed. Here are a couple more...

[Ian.M]

So lets's consider how to get the O.P. something workable quicker than waiting for parts.   IIRC, its important that the Z80 clock signal goes *really* low (max 0.45V) so 1 Vce_sat above 0V is the most it will tolerate, rises fast and cleanly, and swings rail to rail (to reach a minimum of Vcc-0.6V).   This can be achieved by a LS TTL output with a 330R pullup, or with a HC CMOS output.   

I suggest a 74LS74 or 74HCT74 flipflop rigged as divide by 2 to divide the existing clock (or any counter that can divide by two), feeding a 74HC or HCT gate or buffer, with several sections wired in parallel to get a good low impedance clock drive.  As the O.P. says their oscillator is nominally 3.3V, two diodes should be inserted in its Vcc feed to drop the 5V rail to about  3.6V, with 0.1uF decouping right at its Vcc pin.   The LS or HCT flipflops will be compatible with a 3.3V clock signal.  If a LS flipflop is used and the buffer is HC, a 1K pullup on the flipflop output would be advisable.

[NivagSwerdna]

The OP has a 7404 (i.e. U5) and according to the schematic this is enough to drive the Z80 (U2) and 68B50 (U3).  The schematic is I venture well tried and tested.
So the only thing they really need is a XTAL and two small caps. 
I would really like to see the datasheet for the XO but I cannot find anything listed for XO-555BAT

[255]

Is it not possible to replace all the clock circuitry with an integrated oscillator package?

Here is the data sheet of the oscillator I ordered:
https://www.mouser.com/datasheet/2/96/008-0258-0-786357.pdf

[Ian.M]

That oscillator module only guarantees an output  swing from 10% Vcc to 90% Vcc when driving a CMOS load.  10% Vcc isn't low enough for logic '0' into the clock pin for many types of Z80, so for reliability, you'll probably need a 74HC buffer stage to get a true rail to rail clock.

[NivagSwerdna]

Z80 DC Characteristics

Clock Input Low Voltage Min -0.3      Max   0.45V
Clock Input High Voltage Min Vcc-.6  Max   Vcc+.3 V

So definitely living dangerously but you might get away with it.

[255]

So if I feed the output of the oscillator through an inverting buffer before it reaches the Z80 and ACIA, it should be better?

[glarsson]

Yes, but add a pull up resistor (as in the examples above) to make sure the clock high is high enough. Also, if you have more than one spare gate use one for the Z80 and one for the other components.

[Ian.M]

You need a pullup if the buffer is bipolar TTL, (74nn, 74Snn, 74LSnn, 74Fnn) as the totem pole output stage cant drive rail to rail, but not if its CMOS (74HCnn, 74HCTnn etc.) as that will drive rail to rail.  The 330R pullup recommended in the Z80 datasheet should *NOT* be used with a CMOS buffer as the approx 15mA extra the buffer will have to sink will compromise the logic '0' level and is almost certain to take it above the Z80 0.45V logic '0' threshold.

[guenthert]

So if I feed the output of the oscillator through an inverting buffer before it reaches the Z80 and ACIA, it should be better?

So in the time you post it here and get an answer (or multiple so you can pick the one you like), you could just tried it, no?   

And do post results, it's been a long time that most of us dealt with Z80 (and I for one was hoping to never do it again).

[DJohn]

CPUs of that era could be very picky about the clock - not just voltage levels, but rise/fall time as well.  If you feed it through a 74HC14, that's one thing you don't need to worry about.  Put it through a 74HC74 and you'll know that the duty cycle is good too.  You're getting activity on the address bus, so the clock you have now is probably OK.  But it's still worth doing just to be safe.

As guenthert says, pretty much everything in the system, hardware and software, has to be working for you to see data on the UART.  Getting the UART going is generally the end of the "trying to get the hardware to work" stage and the beginning of software development.

The very first thing you do on a Z80 is wire the data bus to 0 (making sure that everything else that might drive it is disabled).  Then have a look at the address lines.  A0 should be toggling quickly, A1 at half that rate, A2 half that again, and so on.  The Z80 does DRAM refresh cycles too, so it won't be quite that simple, but you'll be able to tell if it's happy.  Check that the bus handshaking lines (MREQ, RD, M1) are doing sensible-looking things too.

Then give it a ROM with the simplest program you can: I like a JP back to itself, with the first byte just before a power-of-two address.  That way you can use the appropriate address line as a trigger.  Make sure the CPU can get to your code after reset.  Make sure your reset circuit is good too.  Check every pin on the chip.  Is it doing what you expect it to?

Then you can start testing out I/O devices.  If your program accesses them in a loop, do they get enabled?  Can you make LEDs attached to outputs blink?

Once everything else is going, it's still not trivial to get a UART to talk.  One bit in one config register can be the difference between working perfectly and nothing at all.  And make sure you check the frequency of its clock.  It's too easy to get that wrong.