Grant Searle Z80 SBC troubleshooting

[255]

I took out the RAM and ROM chips, and then tied all 8 data lines to GND. After inspecting each address line upon reset, I do notice that A0 toggles fast, A1 at half that speed, and so on until A7. A7, A8, A9, A10, A11, A12, A13, and A14 are all the same and all oscillate even faster than A0. Is this a problem? MREQ has this weird-looking waveform (see picture), RD looks much cleaner, and M1 looks OK. The reset circuit has been tested and functions properly.

[NivagSwerdna]

I took out the RAM and ROM chips, and then tied all 8 data lines to GND.

Perfect.  Reset Vector is 0000 and 00 is a NOP.  Good job.

After inspecting each address line upon reset, I do notice that A0 toggles fast, A1 at half that speed, and so on until A7. A7, A8, A9, A10, A11, A12, A13, and A14 are all the same and all oscillate even faster than A0. Is this a problem?

Well A0...A6 sound good. Remove U3 as well.

[255]

After removing the ACIA, I still am getting the same signal on A7-A14.

Also, is it a problem that I am using a 74F04 instead of a 74HCT04 for all the inverting logic?

[DaJMasta]

After removing the ACIA, I still am getting the same signal on A7-A14.

Also, is it a problem that I am using a 74F04 instead of a 74HCT04 for all the inverting logic?

Actually yes, maybe.  74F series is an open collector output with a minimal if any current supply when operating high, so it should have a fairly low value pull up resistor on the output, with logic 0 outputs pulling it down internally.

Check the datasheet for your chip, but I'm seeing typical operating output currents in logic high that are slightly negative.

[glarsson]

The Z80 will refresh DRAM by adding refresh cycles. I don't remember the exact timing (been 35 years since I looked into this) but it has an incrementing refresh register that is output on A8 - A15 between nornal cycles. You should sample the address bus when M1 is active (machine cycle 1, opcode fetch).

[Ian.M]

You'll avoid a lot of confusion if you put the Z80 /M1 signal on one channel of your scope, triggering on its falling edge and adjusting the timebase to get a single cycle of it + a bit of the next cycle across the width of the screen, then probe the signal you are interested in on the other scope channel.   You should be using x10 probes, so set the Volts/div to 0.2V for approx 2.5 div high waveforms.  Set the 0V level for the channel showing /M1 to three divs below the centerline and 0V level for the other channel to the centerline.  That way, when you change the signal you probe, you'll see its timing relationship to /M1 and can compare the timing in photos of different signals.

74F and 74AC parts are very fast (for the era) and  can be difficult to use on boards without a ground plane.  You *must* have local decoupling directly across the Gnd and Vcc pins right at the chip.  Anything between 10nF and 100nF ceramic should do nicely.

N.B. a bad clock signal is not an all or nothing thing with a Z80.  I've seen one case with a glitch on the rising edge where the address bus incremented normally as if it was executing NOPs, but the instructions in the EPROM were not being executed.  There were /CS and /OE signals at the EPROM,and it was outputting data on the bus but the Z80 was ignoring it.
The fix was to apply a clock signal that was in-spec with no rising edge glitches, at which point it started executing correctly.

If you want to clock a Z80 slowly with a NE555, use a single feedback resistor from Out to the timing cap, and drive the Z80 clock from the Discharge pin with a 470R pullup resistor to +5V.

[255]

I finally received the 3.6864 MHz oscillator rated for 5V, and the 74HCT04 hex inverter chip. Unfortunately, after inserting the new parts into the board, it still doesn't work. But, I am getting a much cleaner clock signal. Did a bit more debugging with the scope and found that the the TX pin on the 68B50 is always high (obviously) yet, it looks like I am getting some kind of signal on the enable line. The first photo is the new clock signal and the second is the enable line on the 68B50. The /E signal looks like it has a 8% duty cycle or something.

[255]

Does it matter that I am using a 27C64 EPROM instead of a 2764? At this point I'm questioning everything.

[james_s]

No, the 27C64 is CMOS, you're probably not going to find much else these days. The only difference is it uses less power and the programming voltage may be different.

[TomS_]

Quick question, what is the proper way to calculate the baud rate if I swap out the 7.3728MHz crystal for a 4MHz one?

Usually the baud rate is derived from the clock frequency divided by some kind of prescale value. E.g.

4MHz / 115200 = prescale of 34ish nearly 35

Depending on the hardware, you might by able to specify the prescale value, or you might only be able to choose from a preset list.

In the case of a 4MHz clock, you are going to want to concern yourself with the amount of error introduced by the chosen prescale value. A UART should be kept within low single digits of error % (IIRC < 5%). The closer to zero the better. Too much either way and for any given byte, one end of the link could miss entire bits or re-read a bit more than once, which is no good.

115200 @ 4MHz with the following prescale values gives these error percentages:

32: 7.84%
34: 2.08%
35: -0.8%

32 is out of the question, but if you can set 34 or 35 you are golden.

To determine the error rate, use this formula:

prescale * baud / clock

[255]

I ended up getting a 3.6864 MHz oscillator. I run it at 57600 baud since it is half the speed of my original 7.3728 MHz clock.

[MK14]

I ended up getting a 3.6864 MHz oscillator. I run it at 57600 baud since it is half the speed of my original 7.3728 MHz clock.

Did you manage to get it fully working then ?

If not, are all the logic gates/inverters now the 74HCT type ?
They use much less (DC) input current than the older TTL types, so are more likely to work, when the Z80 design doesn't use output buffers.

Also the 68B50 (if I understand things correctly) seems to be overclocked (datasheet seems to say max 1.5MHz, design seems to use around 3.6MHz or 7.2MHz, into its clock input).

One way of finding out if that is causing you problems, would be to half or quarter the clock frequency (i.e. around 1.8MHz or 0.9MHz master clock, to help diagnose the problem), with flip-flops or binary counter/dividers, and see if that makes it work, at the lower baud rates.

I.e. When you overclock (bad idea) the 6850/68B50, it is partly down to luck, if it works or not. Grant Searle seems to like the "overclocking" thing, but in practice, it can cause difficulties in making things work reliably.

[255]

No, my system still does not work. I have replaced the inverter chips with CMOS components but have left the OR-gates used for some of the address decoding as TTL since that is what Grant Searle used in his design. I will try to divide the clock using a flip-flop and see if the 68B50 likes that frequency.

[MK14]

No, my system still does not work. I have replaced the inverter chips with CMOS components but have left the OR-gates used for some of the address decoding as TTL since that is what Grant Searle used in his design. I will try to divide the clock using a flip-flop and see if the 68B50 likes that frequency.

That's good, but for one thing.
"Grant Searle used in his design."

He says in his text:

It is important to use 74HCT devices because:
1. They have extremely small input current requirements so many can be attached to the Z80 buses without any noticeable loading - no buffer ICs are necessary. There should be no problem in attaching a large number of devices providing the bus lengths are kept as short as possible. Quite a reasonable length can be achieved with no instability, though (see my picture below)
2. The outputs are virtually rail-to-rail (ie. 0V or 5V) unlike the 74LS devices.
3. The outputs have strong high and low currents so can drive (for example) LEDs connected to either ground or Vcc easily (must use current limiting resistors, as is normal for LEDs).

The text was mainly concerned about adding interfaces to the design.
http://searle.hostei.com/grant/z80/SimpleZ80.html

What concerns me, is that your method of construction, maybe adding a fair bit of capacitance and interference to the signals (i.e. wires and proto board). So that 74HCT series ICs, are more likely to cope with that. Compared to older TTL, which might cope, but was primarily intended for PCB construction.

If you can easily get hold of the appropriate 74HCT, then I'd suggest trying it. But leaving in older TTL devices, might be ok. But it is not necessarily worth making an order for it, because it only has a small chance of making your thing work.

tl;dr
The 68B50 possible overclocking problems, is the MOST likely thing to be causing your problems. The 74HCT thing, is just icing on the cake, and much less likely to fix your computer.

[MK14]

I've found that (the old generation, original) Z80 processors, have quite weak and sensitive (to capacitance etc) outputs. If there is too much wiring (length etc), and no (output) buffers, it tends to not work.
But if lead lengths are kept reasonable, it should work out just fine.

The 74LS TTL devices were good a long time ago. But don't cope as well as modern 74HCT (and other logic series), do, especially when prototype construction techniques are used. Because the voltages do not have to change by much (e.g. ground bounce), to mess up the logic levels. (Although HCT uses similar input voltages, it has considerably less current flowing, which usually improves things and the much bigger output voltage swing, also helps).

I would suspect that your 74LS device(s), are probably doing just great. I'm probably over-analyzing the situation, while trying to find out why your computer is not working yet.

[255]

I just tried the computer with a 1.8432MHz oscillator I had on hand and nothing. And yes, I did adjust the baud rate accordingly. Even though my computer never showed itself on the terminal, this project was such a good learning experience especially with all the experienced advice I got on this forum. I think I am am going to put it aside for now unless I get any sudden epiphanies. Thanks.

-Adam

[MK14]

There is one way of fixing it, but it would take a lump of time to set up and a modest $money investment.
But it might be worth the investment of a bit of time and money, as it would stand a good chance of fixing it.

Would be to buy one of the low cost logic analyzers currently on the market (I'm NOT familiar with them myself, as I have access to other equipment, which has been fine for me, so far). I think they are around the $20..$35+ mark.
It can then look at many or even all of the digital signals and take real time snap shots of them. This should allow you to see exactly what is going on, and may also be a useful learning exercise and fun.

E.g. Mini Saleae 16 Logic Analyzer USB 100M Max Sample Rate Support 1.2.10 Software U
(But ideally get advice from people who are familiar with what to get).

I beleive there are low cost "clones", available. From e.g. ebay.

https://www.saleae.com/

[MK14]

tl;dr
So you buy or borrow one of the above (logic analyzers), and connect it up to your Z80 computer (and a USB port on a working PC or laptop).
Then by looking at all the extensive signals, you should be able to trace what has gone wrong.
They also can be useful, when fixing hard/complicated software issues.

[jpmkm]

Baby steps.  I'm working on a Z80 system roughly based on Searle's design, and there's no way it would have worked 100% the first time.  Started out with just the Z80 with the data lines pulled low - address lines cycled as expected.  Added ROM, RAM, and decoding logic, along with a latch for some output leds.  Tried just toggling leds and it didn't work.  Pulled the ram out and it still didn't work.  Ended up tracking it down to a bad quad nor chip I was using for my memory reads and writes.  The ROM was never getting its chip select signal.  Changed the '32 and it started working.  So I wrote some more advanced code that involved calls, which requires a stack.  Damn thing didn't work.  Probing around, I found that the RAM's chip select was *always* being held active.  Another damn bad '32 chip.  Replaced that and that started working.  I'm not saying that's what your issue is, but my point is that there are *so* many different chips and wires that must be perfect, it can be hard to troubleshoot an entire system.  Much easier to divide and conquer.  Get at least *something* working(like just the CPU, ROM, and an output latch with some leds), then build from there.