Z80 Homebrew Computer - fault finding

[nockieboy]

Ah, think I've answered my own question.  So I need to swap out the 22pF caps for 33pF and increase R3 to 5K .

I really need to sort the clock out before I start measuring the signals from the 68B50. 

[nockieboy]

Okay, some oscilloscope traces from the 68B50 ACIA chip.  The SBC was running at 3.6864 MHz (albeit with 22pF caps and a 1K resistor, where these should be 33pF and 5K resistor.)

First trace is on pin 8 (CS0) which is the ~M1 signal:

image upload

Second trace is on pin 7 (~IRQ) which is the ~INT signal:

image upload

Third trace is the clock signal itself as it arrives at the 68B50 at pins 3 & 4 (Rx CLK and Tx CLK):

host image online

Next trace is TxDATA (pin 6):

click image upload

That was a difficult trace to stabilise - the edge trigger was especially fiddly to get right.

Last trace is from ~RTS pin 5:

picture uploader

I've tried to get the oscilloscope settings for time/div and volts/div in the images too, but I'm having no luck interpreting these traces.  Seems to me the ACIA is working and sending a signal, so maybe it's just a clock/timing issue with the serial port?

The interrupt signal seems to be especially mangled though - seems like there's multiple voltage levels on that trace, rather than just +5v an 0v?  Also, the last two traces look more like analogue signals than digital/TTL signals...

[PA0PBZ]

Pin 5,6 and 7 don't make any sense at all, I'd say you have problems but it is not immediately clear to me what's going on.
Care to post a picture of your setup?

[grumpydoc]

M1 & clock look good, very clean & sharp edges actually.

INT looks like it is picking up junk from somewhere - make sure it is tied to +5V via a resistor - 2.7k should do and you do not have any inadvertent connections to anything other than the 68B50. For the time being you could disconnect INT and just leave the pullup.

The other look like just noise

Leave the 'scope set up so that 5V is one division, the best way is to have the probe in x10 and the 'scope at 0.5V/div.

[nockieboy]

Pin 5,6 and 7 don't make any sense at all, I'd say you have problems but it is not immediately clear to me what's going on.
Care to post a picture of your setup?

Okay, here's a few pics of my setup - not that it's very clear due to all the address and data bus wires connecting the LEDs up at end.

host image online

Overall setup above.

img host

Closeup of the 68B50 end of the board (USB/TTL lead not attached.)

image hosting over 5mb

Closeup of the 68B50 end of the board, showing the address and data LEDs, USB/TTL connected and board running.  Top right of the board is spare components (resistors, LED, capacitor, crystal)- they're not connected to anything.

Blue wires are address bus, orange are data bus, yellow are control bus.  Green button (inc LED and 555 timer) is single-step clock.  Red button is reset.

I've checked and double-checked the wiring for the 68B50 - it's connected up as per the schematic I posted earlier.

[Bud]

Please pay some respect to your Hitachi scope and clean it, it loks filthy, how you can possibly touch it

[nockieboy]

Okay I've added a 2K7 pull-up resistor to the ~INT line over by the Z80 as per grumpydoc's suggestion.

I know the clock isn't going to be exactly 3.6864 MHz as it's got 2x 22pF caps and a 1K resistor, where it needs 2x 33pF caps (on order) and a 5K resistor, so I'm not even trying to get the serial connection with the laptop working until the caps arrive next week.  I am, however, trying to analyse potential connection issues with the 68B50.

New traces (all with probe set to x10):

Pin 8 - CS0 (~M1 signal)
image upload no limit

These next two traces show the ~IRQ, pin 7, with the signal from ~INT - the first with no pull-up resistor on ~INT (as it was before grumpydoc's suggestion).  I've dropped the volts/div to .2 for these two traces so you can see there's a superimposed signal on the otherwise live (+5V) line on the second trace:
uploading pictures

This second one is WITH the 2K7 pull-up resistor on ~INT:
adult image hosting

However, this is the consistent trace I'm getting for the TxD line now (pin 6):
image upload

That's not looking so good.  RxD is identiical - both are high, which implies the chip is in standby? 

At least I'm getting cleaner signals now...

[grumpydoc]

These next two traces show the ~IRQ, pin 7, with the signal from ~INT - the first with no pull-up resistor on ~INT (as it was before grumpydoc's suggestion).  I've dropped the volts/div to .2 for these two traces so you can see there's a superimposed signal on the otherwise live (+5V) line on the second trace:

That's looking much better.

Remember that \$ \small \overline{INT} \$ is an input to the Z80, from the 68B50. You don't want spurious interrupts or things are going to be quite confusing.

Also, you will always get a bit of noise and pickup from other signals running nearby - it does not matter in digital systems as long as the magnitude is not sufficient to make the system confused about what is a logic '0' or logic '1'. That's why we talk about noise immunity

EDIT: PS: If you don't have pullups on all of the other Z80 control inputs - \$ \small \overline{NMI} \$, \$ \small \overline{BUSREQ} \$ and \$ \small \overline{WAIT} \$ I would add them now.

[nockieboy]

Quote from: grumpydoc on Today at 04:48:47 AM

That's looking much better.

Remember that \$ \overline{INT} \$ is an input to the Z80, from the 68B50. You don't want spurious interrupts or things are going to be quite confusing.

Also, you will always get a bit of noise and pickup from other signals running nearby - it does not matter in digital systems as long as the magnitude is not sufficient to make the system confused about what is a logic '0' or logic '1'. That's why we talk about noise immunity

EDIT: PS: If you don't have pullups on all of the other Z80 control inputs - \$ \overline{NMI} \$, \$ \overline{BUSREQ} \$ and \$ \overline{WAIT} \$ I would add them now.

Yep, I've had pull-ups on ~NMI, ~BUSREQ and ~WAIT as part of the original design (all are 1K resistors though?)  So it would appear that the ~INT line was low before I added the pull-up resistor according to the traces above.  That's odd, as the system seemed to be running okay (the Z80 was incrementing the address bus etc.)

So now TxD and RxD are high, with no variation.  I've checked the connections to the 68B50 and it's all correct, so the chip select signals (CS0, CS1 and ~CS2) should be working as expected and the chip should be active when needed.  I'm going to see if I can get the second trace up and see if CS0/CS1 are high at the same time (as they should be) along with E and ~R/W.

[grumpydoc]

So now TxD and RxD are high, with no variation.  I've checked the connections to the 68B50 and it's all correct, so the chip select signals (CS0, CS1 and ~CS2) should be working as expected and the chip should be active when needed.  I'm going to see if I can get the second trace up and see if CS0/CS1 are high at the same time (as they should be) along with E and ~R/W.

Yes, the next step is to make the 68B50 is being written to correctly, trigger CH1 on IORQ and then go looking with CH2 on your 'scope at the CS[012] and RS pins as well as the enable line (pin 14 should be the inverse of IORQ) and that R/W is getting to the UART correctly.

Also check that you grounded CTS.

[nockieboy]

Yes, the next step is to make the 68B50 is being written to correctly, trigger CH1 on IORQ and then go looking with CH2 on your 'scope at the CS[012] and RS pins as well as the enable line (pin 14 should be the inverse of IORQ) and that R/W is getting to the UART correctly.

Also check that you grounded CTS.

Yes, CTS is grounded along with ~DCD.

Getting a nice inverted IORQ signal to pin 14, E.  CS₀, CS₁ and ~CS₂ are all signalling as expected and should be enabling the 68B50 as required as their signals all coincide properly with the IORQ signal.

TxD and RxD are both still high constantly.

One thing of interest is pin 13 - ~R/W.  It is constantly high.  Having checked the datasheet for the 68B50, it would appear that this pin is high accessing the read-only registers.  This can't be right as the only thing the SBC is trying to do at the moment is print the letter U to the serial bus, so surely this pin should be low?  Grant Searle's schematic shows the ~WR pin of the Z80 connected directly to pin 13 of the 68B50, which is what is happening on my breadboard...

[PA0PBZ]

the ~ or NOT indicates that the function is the inverse of the logic state. So when your ~R/W is high it is in write state, if low it is in read.

[nockieboy]

the ~ or NOT indicates that the function is the inverse of the logic state. So when your ~R/W is high it is in write state, if low it is in read.

Okay, I've gone back to the datasheet for the 68B50 to clarify this. Here's an excerpt from the datasheet: (NOTE: It's actually written as R/~W rather than ~RW as I've written it previously.)

When R/~W is HIGH (MPU read cycle), ACIA output drivers are turned on and a selected register is read.  When it is LOW, the ACIA output drivers are turned off and the MPU writes into a selected register.

Now, I may be mis-reading that but it seems to me that pin 13 should be LOW when writing to the ACIA to output via the serial bus? 

[PA0PBZ]

Now, I may be mis-reading that but it seems to me that pin 13 should be LOW when writing to the ACIA to output via the serial bus? 

If you first write ~R/W and then R/~W... well, that is confusing  In your last definition yes, pin 13 should be low for writing (~1 = 0, ~W = also 0).
It could be a very short pulse, did you try to trigger on it in normal mode and see if anything happens?

[grumpydoc]

the ~ or NOT indicates that the function is the inverse of the logic state. So when your ~R/W is high it is in write state, if low it is in read.

Okay, I've gone back to the datasheet for the 68B50 to clarify this. Here's an excerpt from the datasheet: (NOTE: It's actually written as R/~W rather than ~RW as I've written it previously.)

When R/~W is HIGH (MPU read cycle), ACIA output drivers are turned on and a selected register is read.  When it is LOW, the ACIA output drivers are turned off and the MPU writes into a selected register.

Now, I may be mis-reading that but it seems to me that pin 13 should be LOW when writing to the ACIA to output via the serial bus? 

It's labelled \$ \small Read/Write ~ R\overline{W} \$ indicating that the write function is active low. Active low lines can also be shown using ¬NAME ~NAME or -NAME if you can't write an overbar.

It should be going low to write to the UART, another clue is that it is connected directly to the Z80 \$ \small \overline{WR} \$ signal.

I'd check the wiring.

Now, I may be mis-reading that but it seems to me that pin 13 should be LOW when writing to the ACIA to output via the serial bus? 

If you first write ~R/W and then R/~W... well, that is confusing  In your last definition yes, pin 13 should be low for writing (~1 = 0, ~W = also 0).
It could be a very short pulse, did you try to trigger on it in normal mode and see if anything happens?

 \$ \small \overline{WR}  \$ is low for about two clocks in an IO cycle, so plenty of time to see it on the 'scope.

[PA0PBZ]

@grumpy: I didn't bother to check the datasheet but trusted nockie on this, it will not happen again...

[grumpydoc]

@grumpy: I didn't bother to check the datasheet but trusted nockie on this, it will not happen again...

I think that it was mostly a transcription error.

I suspect that the 68B50 \$ \small R\overline{W} \$ is not connected to the Z80 correctly, we'll know when nockieboy has checked the connections.

You can generate an overbar using the embedded LaTeX mode \$ \overline{thing} \$, I don't know how it displays on other folk's screens but I find a \small before the \overline is about right as well.

[nockieboy]

@grumpy: I didn't bother to check the datasheet but trusted nockie on this, it will not happen again...

  Sorry about that PA0PBZ!  I am pretty new to this stuff and am only realising through trial and error that I have to be extremely explicit when writing information here.

It should be going low to write to the UART, another clue is that it is connected directly to the Z80 \$ \small \overline{WR} \$ signal.

I'd check the wiring.

 \$ \small \overline{WR}  \$ is low for about two clocks in an IO cycle, so plenty of time to see it on the 'scope.

Yep, I thought it should be low hence raising it as an issue earlier.  Unfortunately the wiring consists of one wire which goes straight from \$ \small \overline{WR} \$ on the Z80 to pin 13 R/\$ \small \overline{W} \$.  It's definitely not mis-wired.  I have just checked the signal on the Z80 \$ \small \overline{WR} \$ pin, with no other wires connected to it (there's normally two - one for the 68B50 and one goes to a 74HCT00 for the memory glue logic) and guess what?  The signal is HIGH constantly (with some noise that looks like it accounts for about 1V, certainly not a clean TTL signal.)

It appears that the Z80 isn't trying to WRITE anything?  I'm getting a nice signal on the \$ \small \overline{RD} \$ pin, but \$ \small \overline{WR} \$ is just giving me a jaggy signal between 4-5V...

Here's the signal on the \$ \small \overline{RD} \$ pin (volts/div at .5 with x10 probe):
picture share

And here's the signal on the \$ \small \overline{WR} \$ pin (volts/div dropped to .2 with x10 probe):
free screen capture

That ain't right.   

[grumpydoc]

Time to review the software

[grumpydoc]

Time to review the software

So, the code should be stuck in a loop doing this:

DBUG:          LD        HL,SIGNON1      ; Sign-on message
               CALL      PRINT           ; Output string
               JP        DBUG

PRINT is coded thus:

PRINT:          LD       A,(HL)          ; Get character
                OR       A               ; Is it $00 ?
                RET      Z               ; Then RETurn on terminator
                RST      08H             ; Print it
                INC      HL              ; Next Character
                JR       PRINT           ; Continue until $00


The software interrupt 08 jumps to the transmit routine which looks like this:


TXA:            PUSH     AF              ; Store character
conout1:        IN       A,($80)         ; Status byte      
                BIT      1,A             ; Set Zero flag if still transmitting character       
                JR       Z,conout1       ; Loop until flag signals ready
                POP      AF              ; Retrieve character
                OUT      ($81),A         ; Output the character
                RET



As you are not seeing any writes I would guess that it is reading a 0 for the status bit and sitting in the tight loop jumping back to conout1 repeatedly reading the port, rather than executing the longer loop around outputting a whole string - you should be able to follow the loop on your 'scope.

The first thing I would check is that the data bus is connected correctly to the 68B50 - D0 from the Z80 going to D0 on the UART etc.

EDIT:
The 2nd thing I'd check is that the address lines are correctly connected to the chip select pins and the register select line RS


2nd EDIT:
It's also worth considering whether the CPU is executing the code that we think it is. The best tool would be a logic analyser but as we don't have one the 'scope can be used - trigger on MREQ and get a steady trace on CH1, then go over the other signals with CH2 to see what is happening.

In this case it does look as though we are running the read port/test bit/jump loop.

IN A,($80) consists of an M1 cycle (4 clocks), a memory read (for the port number) which is 3 clocks and then the I/O operation (4 clocks), 11 clocks in all.
BIT 1, A consists of 2 M1 cycles (8 clocks).
JR consists of 1 M1 cycle (4 clocks), a memory read (for the offset) which is 3 clocks, then the jump execution, 5 clocks, if the jump is taken.
So, you should get the following over 31 clock cycles, forgive the bad ASCII  art

Code: [Select]

     | IN A,($80)                            | BIT 1,A                               | JR conout1
     | M1 cycle  |  Mem RD   | IO cycle      | M1 cycle          | M1 cycle          | M1 cycle      | Mem RD    | Jump
CLK  |`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|
M1   |______|````````````````````````````````|_______|```````````|_______|```````````|_______|``````````````````````````````````````

So, basically M1 goes low, then there is a bit of a pause, then three M1 low pulses in a row, then a bit of a pause again and then the cycle repeats.

Happily the trace that you showed of M1 seems to show the above pattern so hopefully it is running the conout1 loop and you've just got a bit of a miswire somewhere.

Otherwise the 68B50 has stuck not transmitting for some reason.

[nockieboy]

As always, thanks for the guidance grumpydoc.    I'll update you when I get the chance to follow this up during the week.

[nockieboy]

2nd EDIT:
It's also worth considering whether the CPU is executing the code that we think it is. The best tool would be a logic analyser but as we don't have one the 'scope can be used - trigger on MREQ and get a steady trace on CH1, then go over the other signals with CH2 to see what is happening.

In this case it does look as though we are running the read port/test bit/jump loop.

IN A,($80) consists of an M1 cycle (4 clocks), a memory read (for the port number) which is 3 clocks and then the I/O operation (4 clocks), 11 clocks in all.
BIT 1, A consists of 2 M1 cycles (8 clocks).
JR consists of 1 M1 cycle (4 clocks), a memory read (for the offset) which is 3 clocks, then the jump execution, 5 clocks, if the jump is taken.
So, you should get the following over 31 clock cycles, forgive the bad ASCII  art

Code: [Select]

     | IN A,($80)                            | BIT 1,A                               | JR conout1
     | M1 cycle  |  Mem RD   | IO cycle      | M1 cycle          | M1 cycle          | M1 cycle      | Mem RD    | Jump
CLK  |`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|_|`|
M1   |______|````````````````````````````````|_______|```````````|_______|```````````|_______|``````````````````````````````````````

So, basically M1 goes low, then there is a bit of a pause, then three M1 low pulses in a row, then a bit of a pause again and then the cycle repeats.

Happily the trace that you showed of M1 seems to show the above pattern so hopefully it is running the conout1 loop and you've just got a bit of a miswire somewhere.

Otherwise the 68B50 has stuck not transmitting for some reason.

Wow - thanks for that grumpydoc, awesome detail in your reply!!    I had a spare five minutes at lunch to get the multimeter out and test the connections between the Z80 and the 68B50.  Unfortunately I haven't found any wiring errors on the address, data or control buses.  It does look as though the Z80 is stuck in the conout1: loop from the M1 signal.

If I understand it correctly, BIT 1,A is testing to see if the 68B50 is already transmitting something and holding until it says it's clear?  So it looks as though the 68B50 is erroneously reporting that it's transmitting when it isn't?

[nfmax]

Jumping in (feet first) with a couple of comments:

• Both the

Code: [Select]

CALL and

Code: [Select]

RST

instructions should generate two write pulses, to write the current program pointer into RAM at the stack pointer location. You aren't seeing these (I think) therfore the fault is not restricted to the ACIA wiring. Check the /MEMWR signal[/li]

• I assume you are using Grant's Z80 circuit: check the wiring to U7A pin 1 actually goes to pin 1. If you have accidentally wired the Z80 /WR output to an LSTTL output (which is at a logic high) instead of an input the feeble Z80 output driver will be unable to pull it low. From your screenshot, it might be trying to do this

[nockieboy]

Jumping in (feet first) with a couple of comments:

• Both the

Code: [Select]

CALL and

Code: [Select]

RST

instructions should generate two write pulses, to write the current program pointer into RAM at the stack pointer location. You aren't seeing these (I think) therfore the fault is not restricted to the ACIA wiring. Check the /MEMWR signal[/li]
[li]I assume you are using Grant's Z80 circuit: check the wiring to U7A pin 1 actually goes to pin 1. If you have accidentally wired the Z80 /WR output to an LSTTL output (which is at a logic high) instead of an input the feeble Z80 output driver will be unable to pull it low. From your screenshot, it might be trying to do this[/li]

Welcome nfmax - any input is appreciated, feet first or not!    There's some food for thought there - yes, I'm using Grant's Z80 circuit almost to the letter.  The only differences are that I'm using the USB/TTL serial connection rather than the RS232 and my RAM/ROM chips are much larger (which just means the higher addresses are grounded so only the lower 64K (SRAM) and 8K (ROM) are used.)

[grumpydoc]

Jumping in (feet first) with a couple of comments:

• Both the

Code: [Select]

CALL and

Code: [Select]

RST

instructions should generate two write pulses, to write the current program pointer into RAM at the stack pointer location. You aren't seeing these (I think) therfore the fault is not restricted to the ACIA wiring. Check the /MEMWR signal[/li]
[li]I assume you are using Grant's Z80 circuit: check the wiring to U7A pin 1 actually goes to pin 1. If you have accidentally wired the Z80 /WR output to an LSTTL output (which is at a logic high) instead of an input the feeble Z80 output driver will be unable to pull it low. From your screenshot, it might be trying to do this[/li]

Yes, they should both write the stack but the CPU definitely looks to be stuck in the loop testing the modem status bit and in that loop there are no memory writes.

It won't hurt to (double) check the wiring though.

Wow - thanks for that grumpydoc, awesome detail in your reply!!    I had a spare five minutes at lunch to get the multimeter out and test the connections between the Z80 and the 68B50.  Unfortunately I haven't found any wiring errors on the address, data or control buses.  It does look as though the Z80 is stuck in the conout1: loop from the M1 signal.

If I understand it correctly, BIT 1,A is testing to see if the 68B50 is already transmitting something and holding until it says it's clear?  So it looks as though the 68B50 is erroneously reporting that it's transmitting when it isn't?

It says that something has been loaded into the transmit register which has not transmitted yet - normally I would expect that is because it is still being sent. The only reason I can see for the current situation, assuming the Z80 is correctly wired to the 68B50 is that it does not have a transmit clock.

I find myself wondering whether this 68B50 does not like being overclocked?

What clock are you currently running things at?