Z80 Homebrew Computer - fault finding

[nockieboy]

Hi everyone,

Firstly, apologies if this is in the wrong forum category, but I'd appreciate some help/guidance with a fault I've got on my homebrew Z80 computer that I've been building.

It's all built on breadboard currently, but it's at the stage where I should be able to connect it up to my laptop and get it running via a USB/TTL connection.  It's heavily based on the design by Grant Searle here http://searle.hostei.com/grant/z80/SimpleZ80.html, I've just got bigger SRAM/ROM chips as it seems the smaller ones are harder (and more expensive!) to get these days.

The issue is, it's not playing.  I had a (pretty serious) issue with it when I first powered it up - it was drawing about 1.2 amps, which isn't great, and after some inspection I realised I'd connected up the 68B50 ACIA backwards to the power supply (!) thanks to a silly mistake I made over Vcc/Vdd/Vss etc labelling.  I'm assuming it blew the chip, so I swapped it out for a fresh one. Still no go with the communication with the laptop, though.  So I built a simple display for the address and data buses using spare LEDs and a single-step clock to see what was going on at the lowest level.

After some investigation, it would appear that the Z80 is starting up just fine and reading/executing the instructions in the first 2 bytes of ROM without error.  The problem is when it gets to the 3rd byte, a value that means D0 on the data bus needs to be low.  But it seems D0 is high on every single address.    I don't think this is a short circuit as D0 goes low when the rest of the data bus is inactive, but for every read/write, D0 is high. 

Unfortunately my electronics experience/knowledge is pretty poor, so other than checking the connections to make sure it's wired up properly I'm a little stumped for ideas. 

I'd appreciate any suggestions/advice at all that'll help me get to the bottom of this.  I'll go through the wiring and connections later this week, but if anyone has had this issue before and/or knows what the cause may be (another damaged chip perhaps or a definite wiring error?) then I'd be very grateful for your comments. 

Thanks!

[IanJ]

Hi,

Back in the 80's & 90's I built a good few Z80 powered system for offshore.......home brewed pcb's and designed and built from scratch. There were quite a few issues and wierd symptoms which sometimes resulted in the fix not being where you first thought. So, from memory here's a few things I'd look at or test......assuming the basic design is good.

- Put a cap across the reset switch so that the Z80 gets a soft start.
- Run it with a crystal within spec, or divide by 2 (flip flop) in place of U5:B
- Is the oscillator double oscillating? Try a 74LS04 rather than HCT......or a different brand, or add a 33pF cap across the clock to test.
- Try an HCT version of the 74LS32 for the address decoding.
- Remove U3 just incase it's interfering with the core functionality.
- Have you thought about extending the capabilities of the memory and IO decoding to allow you to play with the memory and IO map. You might get some ideas from my ZX Spectrum interface here - http://www.ianjohnston.com/images/stories/IanJ/ZXspectrummod/ZXSpectrumMultiIO.pdf

Always great to see new build Z80 systems.........Good luck.

Ian.

[nockieboy]

Thanks for the replies guys.   Okay, wilfred, in reply to your post:

What is in the first three bytes of the ROM? Does it match what you think should be there?
You have made a decent attempt to describe the problem but It might still be difficult to diagnose.

I am betting it is either a wiring error or the ROM does not contain what you think it contains. But it still could be  a variety of things.

The first rule of debugging others projects is to trust but verify. Which is hard on the forum without being able to probe the circuit yourself. In other words every claim you make needs to be double checked. Everyone here will know how blind you can get to your own mistakes. You build up a wall in your mind that you refuse to look over. The only way past it is to methodically check everything and assume nothing.

Yes, I'm getting results that I would expect from the ROM on the data bus.  I can remove the ROM and verify its contents to make sure, but I checked it before removing it from the EEPROM programmer and it was showing the correct data then.

IF the ROM delivers bit D0 on the first two bytes AND there is a wiring error that masks the bit and gives the same value anyway then you may not see the error until the third byte.

I'm sure that's precisely what is happening.  The first three bytes are F3 C3 B8 - both F3 and C3 are appearing on the data bus as they should do (note that both have D0 high naturally) but the third memory location (B8) is showing as B9 on the data bus as D0 is still high when it should be low.  The fourth byte is 00 and is showing as 01 as D0 is high. I've stepped through quite a few memory locations now and every single one has D0 high, whether or not it should be high or low according to the value at that address.

I guess the main reason for posting this issue for advice is that two heads are better than one and, as you say, it's easy to get trapped into a very narrow mindset when you're so close to the problem (and, in my case, pretty inexperienced at electronics generally.)  I'm supposing it's a bad connection somewhere, but it strikes me as odd that D0 is only high when the bus is active. I'd have thought a short would make it high all the time?

In any case, I'm hoping to have a more detailed look at the wiring this evening and make some progress on the issue!

Back in the 80's & 90's I built a good few Z80 powered system for offshore.......home brewed pcb's and designed and built from scratch. There were quite a few issues and wierd symptoms which sometimes resulted in the fix not being where you first thought. So, from memory here's a few things I'd look at or test......assuming the basic design is good.

- Put a cap across the reset switch so that the Z80 gets a soft start.
- Run it with a crystal within spec, or divide by 2 (flip flop) in place of U5:B
- Is the oscillator double oscillating? Try a 74LS04 rather than HCT......or a different brand, or add a 33pF cap across the clock to test.
- Try an HCT version of the 74LS32 for the address decoding.
- Remove U3 just incase it's interfering with the core functionality.
- Have you thought about extending the capabilities of the memory and IO decoding to allow you to play with the memory and IO map. You might get some ideas from my ZX Spectrum interface here - http://www.ianjohnston.com/images/stories/IanJ/ZXspectrummod/ZXSpectrumMultiIO.pdf

Always great to see new build Z80 systems.........Good luck.

Ian.

I was playing games on my Z80-based Amstrad CPC464 and teaching myself to program back in the (mid-late) 80's - funny how I've got the bug now to actually build one.  Never realised it was so (relatively) simple!  Thanks for the pointers - currently I'm running with a de-bounced switch to step the clock manually so that I can see exactly what is on the address and data buses - it was invaluable in finding the 'permanently high D0' issue which is the major bug I'm trying to fix.  All my glue chips are HCT (at the moment that's just a 74HCT04 inverter and a 74HCT00).

I'll take the ACIA (68B50) out of action then and see if there's any change.  Shouldn't make a difference I wouldn't expect as it's not active all the time (only when the monitor program is trying to send or receive data from the USB/TTL connection which doesn't happen straight away.)

So at the moment it's looking like a wiring error do we think?

[grumpydoc]

Have you checked all the wiring - no shorts on D0 to anything else?

Have you checked that the RAM or 68B50 are not trying to drive the data bus, especially if the 68B50 is the same one that you reversed the supply to.

If the chips are in sockets you could try removing the RAM or 68B50 and see if that helps.

[Fungus]

Step to byte 3, break the D0 connection to the ROM, see if it measures high on the ROM chip.

If not, work your way back towards the Z80 and find out what's pulling it high.


(...and consider getting a current-limited power supply for the next time you power on a prototype like this)

[nockieboy]

A

Have you checked all the wiring - no shorts on D0 to anything else?

Have you checked that the RAM or 68B50 are not trying to drive the data bus, especially if the 68B50 is the same one that you reversed the supply to.

If the chips are in sockets you could try removing the RAM or 68B50 and see if that helps.

Thanks grumpydoc - yes, since my last post I've had a spare 5 mins to check the wiring.  I've checked the D0 line with my multimeter in resistance mode - no shorts to any other data lines and as the circuit is fairly simple (it's all on 3 breadboards) it's easy enough to do a visual inspection and confirm there's no wrong connections with the D0 line.

Didn't think about checking the RAM or 68B50 to see if they're driving the bus as well.  In theory, both should be disabled whilst the lower 8K memory space is addressed, but it's well worth checking I guess.

The chips aren't in sockets, but they are in my breadboard... I could remove them if I re-wire part of the address bus (I got lazy and just ran a couple of the address wires over the top of the ROM chip instead of around it.  Is there any reason disconnecting them from the +5V rail wouldn't work as well?

Step to byte 3, break the D0 connection to the ROM, see if it measures high on the ROM chip.

If not, work your way back towards the Z80 and find out what's pulling it high.

(...and consider getting a current-limited power supply for the next time you power on a prototype like this)

Marvellous. Why didn't I think of that? Soon as my work is done, that'll be my next plan of attack with this problem. Thanks for the advice re: the current-limited power supply. That's a mistake I've learned from, I can assure you! Thanks Fungus!   

[nockieboy]

Okay, now I'm getting confused. 

I followed Fungus' advice and stepped to the third instruction, which should be B8.  The data bus shows B9, with D0 being erroneously high.  I disconnected D0 from the ROM and checked the pin - it was showing HIGH.  This would indicate that the value B9 was at that memory address when it should have been B8 - i.e. an error with the ROM.  Nothing else was connected to the D0 pin other than the indicator LED I'm using to view the data bus.

So I removed the ROM chip from the breadboard, plugged it into my EEPROM and read the data back off of it.  As you can see from the attached image, the data on the ROM is fine and the EEPROM programmer is able to read the data without any problems.

I'll post a picture of the breadboard setup shortly - although I don't know if that will help, it's a bit of a bird's nest... 

[PA0PBZ]

Okay, now I'm getting confused. 

Are you sure that your address lines are correct? Maybe you are not looking at address 0002?

[grumpydoc]

Just noticed this

I've just got bigger SRAM/ROM chips as it seems the smaller ones are harder (and more expensive!) to get these days

What did you do with the extra address lines?

Also curious to know how you are "stepping to the 3rd byte" on a bare bones Z80 with no working monitor program and no single step hardware?

[nockieboy]

Are you sure that your address lines are correct? Maybe you are not looking at address 0002?

Yes, as sure as can be.  Address 0, 1 and 2 are showing up on the address bus LED's correctly in binary, so no reason to think 3 would be wrong?

Just noticed this

I've just got bigger SRAM/ROM chips as it seems the smaller ones are harder (and more expensive!) to get these days

What did you do with the extra address lines?

Also curious to know how you are "stepping to the 3rd byte" on a bare bones Z80 with no working monitor program and no single step hardware?

The extra address lines are all tied low to GND.

I've got a de-bounced switch that I am using to clock the Z80.  Each click of the switch generates a single 1-second high pulse from a 555 timer to the CLK line of the computer.  The address bus lines A0-A7 have LEDs on them so I can see the bottom 8-bits of the address bus and the data bus has 8 LEDs on it so I can see the entire data bus in binary.

[CJay]

Handy that it's a Z80, remove the ROM from your system and make a NOP exerciser, you can then test all address lines to make sure they're all working as expected and wired correctly to the various peripheral chips, glue logic etc.

[grumpydoc]

Handy that it's a Z80, remove the ROM from your system and make a NOP exerciser, you can then test all address lines to make sure they're all working as expected and wired correctly to the various peripheral chips, glue logic etc.

Sadly nockieboy did not socket the chips - always a good idea when building prototypes.

BTW have you checked that the D0 line really is hgh and you did not just make a mistake with the LED - do you have a buffer of some sort between the data bus and the LED?

[nockieboy]

Handy that it's a Z80, remove the ROM from your system and make a NOP exerciser, you can then test all address lines to make sure they're all working as expected and wired correctly to the various peripheral chips, glue logic etc.

Sadly nockieboy did not socket the chips - always a good idea when building prototypes.

It's all on a breadboard, so not an issue...

BTW have you checked that the D0 line really is hgh and you did not just make a mistake with the LED - do you have a buffer of some sort between the data bus and the LED?

Well, I'm going to go back and test D0 from the ROM again without the indicator LED attached.  No, there's no buffer between the data bus and the LEDs... erm... will that make a difference? I'm more a software than hardware person.. 

I'm attaching some images of the prototype - no doubt they'll attract more critical comments than anything else, but please remember I'm a beginner at electronics! 

[spudboy488]

Maybe D0 is stuck high somehow. D0 is high for the first 2 bytes so you may not see it. Check byte 4 (if possible) to see if the 0x00 reads back as 0x01.

[nockieboy]

Maybe D0 is stuck high somehow. D0 is high for the first 2 bytes so you may not see it. Check byte 4 (if possible) to see if the 0x00 reads back as 0x01.

D0 is most definitely stuck high - I'm trying to work out why or how.  I disconnected the D0 bus from the ROM earlier when address 3 was selected and the D0 pin on the ROM was high when it should have been low - but when I removed the ROM and verified its contents in my EEPROM programmer, it was fine.   I'm starting to wonder if I have introduced this issue into the system with the indicator LEDs, thanks to a question from @grumpydoc earlier asking if I'd buffered the address bus before connecting the LEDs...

[CJay]

Yes, it most definitely can make a difference if there's no buffer but it depends on things like how many chips you're 'driving', the forward voltage of the LED (it may be lower than the guaranteed 'high' input voltage and actually be causing a fault instead of indicating one)


The NOP exerciser will only help verify your address lines but that is useful in itself, if you wire the NOP into the ROM position on your board it will verify the databus wiring (but not a problem with levels)

[nockieboy]

Yes, it most definitely can make a difference if there's no buffer but it depends on things like how many chips you're 'driving', the forward voltage of the LED (it may be lower than the guaranteed 'high' input voltage and actually be causing a fault instead of indicating one)


The NOP exerciser will only help verify your address lines but that is useful in itself, if you wire the NOP into the ROM position on your board it will verify the databus wiring (but not a problem with levels)

Hmm.. I think I'll run D0-D3 through an inverter as I have a few spare on the breadboard - that should be okay as a buffer to drive an LED, right?  At least that'll show if there really IS an issue with D0 and it's not something I've introduced myself...  Failing that, I'll set up the NOP instruction in place of the ROM and see if the address bus is working as expected. In fairness, I did the basic NOP test on the Z80 before I added the RAM/ROM, but that was before the address bus was wired in.

[grumpydoc]

You definitely need a buffer - the Z80 I/O pins are only designed to drive one TTL load if memory serves - something like max sink current 2ma at logic '0' and max source current 250uA for logic '1'.

The RAM & ROM are probably similar.

[nockieboy]

You definitely need a buffer - the Z80 I/O pins are only designed to drive one TTL load if memory serves - something like max sink current 2ma at logic '0' and max source current 250uA for logic '1'.

The RAM & ROM are probably similar.

Yep, you're spot on grumpydoc.    Instead of running D0 through a LED and resistor, I switched it over to one of the 74HCT04's spare inverters (well, two actually so the output wasn't inverted) and then through the LED.

Funnily enough, the permanent high on D0 disappeared and the results were fine.  I'll have to spend a little time creating a proper buffered address/data bus display (I actually have some 74HCT244's and 74HCT245's as my plan is to fully buffer the address, control and data buses later) so I can view the address/data buses without causing more problems.

The reason for wanting to see the address/data buffer was because the Z80 wasn't talking to my computer in the first place.  The next thing for me to look at after this is the clock (the 8MHz clock, not the temporary single-stepper I've created) and making sure the 68B50 is is receiving the chip select signal properly.

Oh, one other thing - I've got decoupling capacitors on the Z80, RAM and ACIA but not on the ROM - didn't get round to putting it in there.  I wonder if that could be causing the communication issue?

[nockieboy]

Okay, progress update.  The D0 high bug is fixed.  The SBC still isn't talking to my laptop though, which was the original issue that caused me to create the bus display (which introduced the D0 high bug!)

I've now taken a look at the 8MHz clock through my old oscilloscope (I say old because I got it cheap off eBay and it's limited in features and probably had a million previous owners and is a little tatty, dodgy and uncalibrated as a result.)

Here's a pic of the oscilloscope trace from the 8MHz clock output:

image hosting 30 mb

That was taken with the following settings: volts/div: 5, time/div: .2u(micro) seconds.

Now, I know next to nothing about oscilloscopes as well as electronics, but it seems to me that the voltage on the clock output could be a little high (although that could be a calibration issue? Trace shows good and accurate on the oscilloscope's built-in calibration connection though) and, most obviously, the signal isn't very clean (is that wave deformation at the leading edge of the on-pulse called 'overshoot'?)  Also, from some basic mental arithmetic looking at the signal trace and timebase, it looks like it's running at a frequency around 11MHz, when it should be 7.328MHz (or thereabouts).  Now, that was hardly a scientific analysis from an uncalibrated oscilloscope, it's a ballpark figure, but does seem to be too high.  Is that right? 

The clock is set up exactly as per the schematic in Grant Searle's design http://searle.hostei.com/grant/z80/Z80SbcSchematic1.2.gif.  I don't know if the signal is picking up noise on the leads I'm using (they're just BNC connectors, some wire and crocodile clips on the end - like I said, I'm not a professional!) or if the clock circuit just isn't producing a clean signal.

So, two questions arise: -

1) Is the clock signal causing problems that would cause the Z80 SBC not to work properly?
2) How could I improve the clock circuit to remove these errors when it's set up as per the instructions?
3) (Bonus question, or I can't count..) Where else should I start looking for issues if the clock is passable, yet I'm still getting nothing at the terminal on my laptop?

As always, thanks for any help/suggestions or just passing the time of day with a scatty and slightly inept hobbyist! 

EDIT:  Actually, thinking about it, that waveform deformation is almost certainly interference or impedance in the oscilloscope wires I'm using, I'd guess?  The waveform goes through two inverters before going out to the CLK bus line, so it should be a square waveform, right?

[PA0PBZ]

The waveform is fine as it is displayed on the scope, but the frequency is not, it really looks like 11MHz. In the best case this would mean that your serial timing would be wrong, but you should still see some random stuff on your laptop. Otherwise the clock could be too high for the 68B50 or even for the CPU, I didn't check the datasheets so that is something for you to do if you feel like it. Do you have another crystal? Coud be something wrong with it, or try to increase C5 and C6 to 47p and see what happens.

[CJay]

Mhmm, .1uS or slightly less per full cycle would indicate at least 10MHz, that could be affected by your choice of 'scope lead but I'd find it difficult to believe 2-3MHz so either the crystal is wrong/faulty or your 'scope is *way* out of cal. (suspiciously close to 11.0592MHz though, which is a clock frequency used for serial comms).

Can you 'scope the output of the 68B50 and see if it's even attempting to communicate?

Check that the vertical and horizontal controls on the 'scope don't have a manual adjust knob on them as well.

You can do a rough check of the 'scope's vertical calibration if you have a multimeter (connect it and the 'scope to a battery and see if they agree) and you can check the horizontal timebase if you can find a crystal oscillator module with the frequency marked on it (one of the square or rectangular metal can type that need 5V)

Adjusting the 'scope so a waveform fills as much of the screen as you can spare makes it easier to get more accurate measurements, same goes for horizontal timebase, change the timebase so you get fewer full cycles displayed.

Definitely buy a 'proper' 'scope probe though, they're not expensive on eBay.

[PA0PBZ]

Adjusting the 'scope so a waveform fills as much of the screen as you can spare makes it easier to get more accurate measurements, same goes for horizontal timebase, change the timebase so you get fewer full cycles displayed.

In this case the horizontal setting is fine:

[CJay]

Adjusting the 'scope so a waveform fills as much of the screen as you can spare makes it easier to get more accurate measurements, same goes for horizontal timebase, change the timebase so you get fewer full cycles displayed.

In this case the horizontal setting is fine:

Absolutely, it's good enough in this case that it's obvious the clock is not 8MHz so that's a handy indication and all we really need to to know to suspect the clock circuit, my comment was more as a general tip for future reference when differences aren't quite so obvious.

[grumpydoc]

The waveform on the 'scope looks fine, I'm guessing that you have it in the fastest horizontal setting which means (further guess) it is a 20MHz 'scope.

Looking at an 8Mhz (or 10, or 11Mhz) square wave on a 20Mhz 'scope is going to allow you to say there is something there and it is oscillating - as the first odd harmonic is 24Mhz it is going to be more than 3dB down so you will get no fidelity in the waveform at all.

As to frequency - well, I would not trust a 2nd hand 'scope off ebay (unless I happened to be selling it) to tell the difference between 8Mhz and 11Mhz. I think the possibility of use of the variable timebase knob (accidentally or otherwise) has been mentioned so it is worth checking that the 'scope is correctly set up.

I am a little surprised that the design calls for a 7.3728MHz clock. While this is the correct clock frequency for 115200 baud using the 68B50 in clock/64 mode it is too high for the spec which says the maximum Tx or Rx clock is 1.5MHz, it is also pretty high for a Z80 - you can get 8MHz Z80's (the Z80H) but you would have to be careful to order that part and not "just" a Z80.

It is also a very ambitious frequency to have on a breadboard!

Finally, if you *do* have an 8Mhz crystal I am not too surprised that your serial comms don't work - compared with 7.3728Mhz that is nearly 8% high - generally RS232 needs the total timing error to be within 5%

On the breadboard I would drop the clock to 1 or 2MHz (divide the 7.37Mhz clock by 4 to give 1.8Mhz which is still over spec for the 8B50 but probably close enough).