Z80 Homebrew Computer - fault finding

[PA0PBZ]

Here's the deal with INT:

(For INT mode 2)

Low address from the interrupting device, here the SIO

Code: [Select]

LD A,$02
OUT (SIOB_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOB_C),A
High address from the I register:

Code: [Select]

; Interrupt vector in page 0
LD A,$00
LD I,A

IM 2
EI
INT routine then set up at correct address:

Code: [Select]

.ORG $0060
.DW serialInt
SIO activates INT when it feels like it and offers the low address on the bus, Z80 jumps to address constructed from I for high 8 bits and bus address fro low 8 bits (maybe 7, low address seems to be even)

[C]

If you are wired correctly?
then
   Grant's Code should work if he really tested the code for channel A only op

   If this is case that he did test it, then he could have had the MAX232 always connected.

So If grant tested channel A with MAX232 on B then state of inputs to B that are connected to Max232 only remain. That is just RXDB
 
Have you tried grant's un+modified code lately?

Here's the deal with INT:

(For INT mode 2)

Low address from the interrupting device, here the SIO

Code: [Select]

LD A,$02
OUT (SIOB_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOB_C),A
High address from the I register:

Code: [Select]

; Interrupt vector in page 0
LD A,$00
LD I,A

IM 2
EI
INT routine then set up at correct address:

Code: [Select]

.ORG $0060
.DW serialInt
SIO activates INT when it feels like it and offers the low address on the bus, Z80 jumps to address constructed from I for high 8 bits and bus address fro low 8 bits (maybe 7, low address seems to be even)

Good summary
  From what I have read,  D0 of a vector must equal 0

[nockieboy]

Okay well I've burned an original copy of the monitor code, with no edits or debugging in it.

I've tried it connected to port A and to port B, both yield exactly the same results - the initial 'Press [Space] to continue' message is printed to the terminal, but nothing after that.

Assuming the monitor code uses interrupts to trigger the appropriate code to receive data from the USB/TTL connection, then the only assumption I can make is that the interrupt isn't working for some reason.  I've checked the connection between the SIO INT and Z80 INT pins and there's no issues there...

[C]

Try something dumb

Start sending SPACES from PC and continue sending

Then press the cold reset to restart Z80

should still get 'Press [Space] to continue'
but might see a change in what is sent from Z80

[C]

The SIO uses M1

This tells when to put a vector on bus
When interrupt service is done.

If M1 is not connected properly then No vector on bus
Bus could be anything during vector read.

Grant's drawing is SIO pin 8 to Z80 pin 16
 

IEI SIO pin 6 also

[C]

From what I read in Grant's code

SIO Output characters
  sent from any place in program, not interrupt driven

SIO Input characters
Interrupt to buffer store
if too many characters in buffer then RTS_High and when connected to USB_CTS should stop more characters being sent.

At some point in main code there should be a SET RTS_Low to enable USB to send more characters.

Main code gets characters from buffer.


Putty like programs
  Most programs like this have an option to echo characters sent. This should be OFF.
  To Test your putty program only echoes when you have USB_TX Connected to USB_RX

For Grants software you want hardware handshake. This enables USB_CTS input to stop the sending of more characters. No handshake should work with loss of characters in Z80 when buffer is too full.

If you turn off hardware handshake the the risk is talking to fast to Z80 and causing a buffer overflow. This should only trash some received characters or cause some characters to be dropped.

With the problems being the Z80 receiving characters,
  USB_CTS could stop the sending of characters to Z80

, just to be complete.
  USB_RST is control used to stop Z80 sending characters.

If you strapped both CTS Low then both sides should always transmit characters.
You would only have
USB_TX to Z80_RX
USB_RX to Z80_TX
USB_Ground to Z80_Ground
between USB & Z80
If Z80 is powered from USB then USB+5 to Z80+5

Putty could them be set to
   8 bits 1 stop
With CTS strapped the hardware handshake setting will not matter.
Software handshake should not be used.
   
Think that PA0PBZ may have tested this

In any case
 You can disconnect the wires to USB_CTS and strap to low level(ground) to guarantee the sending of characters to Z80 with  settings of no handshake or hardware handshake in putty
.

[nockieboy]

The SIO uses M1

This tells when to put a vector on bus
When interrupt service is done.

If M1 is not connected properly then No vector on bus
Bus could be anything during vector read.

Grant's drawing is SIO pin 8 to Z80 pin 16
 

IEI SIO pin 6 also

M1 is connected to the Z80 and both pins are showing continuity with each other.
IEI is connected to +5V.

I think you mean SIO pin 8 to pin 27 on the CPU for M1?  Pin 16 is INT.

No luck with pressing the spacebar constantly prior to cold starting the SBC either.

[nockieboy]

If you strapped both CTS Low then both sides should always transmit characters.
You would only have
USB_TX to Z80_RX
USB_RX to Z80_TX
USB_Ground to Z80_Ground
between USB & Z80
If Z80 is powered from USB then USB+5 to Z80+5

Putty could them be set to
   8 bits 1 stop
With CTS strapped the hardware handshake setting will not matter.
Software handshake should not be used.
   
Think that PA0PBZ may have tested this

In any case
 You can disconnect the wires to USB_CTS and strap to low level(ground) to guarantee the sending of characters to Z80 with  settings of no handshake or hardware handshake in putty
.

I've just tried this:
* SIO CTSA tied to ground
* USB CTS tied to ground
* RTS disconnected (and later also tied to ground)
* Just TXA and RXA and power connected. 
* No handshake on the terminal. 

Powered up the SBC - no chars echoed.  Cold reset the SBC.  Initial message displayed (press space etc).  No chars echoed.

INT is tied high as per the schematic, but I've just checked the resistor and it's a 470 ohm one. NMI and HALT are pulled high through 1k resistors.  Just wondering the Z80 or SIO has enough to pull the line low with that resistor?  I note it's a 4k7 resistor in the schematic.  I think I might have gone colourblind or just used the wrong resistor....

EDIT:

Nope, I've swapped the 470R for a 4K7 resistor on the INT line, still not working.

[C]

Yes
  470 is way to low

4K7 or greater

Now I am wondering if you might have fried the INT output of the SIO

If you can still see SIO INT pin changing the should still be ok.

[C]

Yes
M1 is on Z80 pin 27
Int is on Z80 pin  16
checked Z80 datasheet again just to be sure, Grant's drawing is correct.
Was a typo.

If you have a working USB to serial TTL adapter it should just work.

I would guess that you have checked continuity of all the connections by now many times. Are you checking actual pin on chip to pin on chip when doing this?

You receiving text on PC suggests that most connections between Z80 & SIO are correct.
  If you had a data bit swapped then you could program SIO wrong, but the receive text would also be changed if it worked.
  A miss wire for SIO pins 34 & 33 B/A & C/D should also mess up text.

The special pins for  interrupt for receive is
IEI pin 6 to +5V
M1 pin 8
SIO INT pin 5 to Z80 pin 16 with a pull-up to +5
     You should see +5v on both these pins when there is not an interrupt in progress.

Think you have connected USB properly and then
  Removed connection to USB_RX & connected USB_TX to this pin (USB_RX). This should give you an echo of what is typed on PC. If you then remove just the USB_TX to USB_RX, then echo should stop. This should be a fair test of your USB adapter is working.
Might check the level of USB_CTS pin
   
Just in case you do not understand.
When you send characters out a serial port, the device at other end will echo them back if needed.

So the test above is sending out to the end and the connection at end causes what is sent to come back.

Some devices never echo back. In this case to see what you are typing you turn on putty's ECHO

 

[nockieboy]

Yes
  470 is way to low

4K7 or greater

Now I am wondering if you might have fried the INT output of the SIO

If you can still see SIO INT pin changing the should still be ok.

Is that likely? (That I've fried it?) I've got another SIO but changing it will be a pain with all the wires over the chip.

Yes, I've checked continuity repeatedly from pin to pin, but won't hurt to look again tomorrow as I feel I'm running low on options now. Will get the scope out and try to get some levels on INT etc.

[C]

Think you might say that 470 was a dumb error.

From what is happening, think you have something else dumb.

When checking pins is good to do it many times as very easy to miss count.
Pick a chip or connection jack, then check every pin in order
So by checking Z80 in order you would have checked each connection to SIO

When checking the SIO in order you will check again pins from Z80

By testing medal of pin on each chip, you are checking breadboard connections and wires.

=======
If you see a level change on INT should be ok.

Hint for breadbord
  don't go over chips.
  this design is easer if you create a bus at the end of board where you can.
If you put Z80 on bread board and waste some of the end of that breadboard to create a bus then in future you can do an easy add or change.


Keep checking back using Grant's UN-modified code in case there is an error in your code changes.
 

[C]

Easy to make a dumb error, I have made many.

You are so close to have a working SIO that a small error or poor connection could be the cause.

One thing that you need to be careful of when building on a breadboard is that you do not harm the chips you are trying to use.

This requires some care

If you look through Grant's stuff you should see some chip labels, This can help some.

One thing you need to be very careful of the what type of pin on a chip you are dealing with.

Some are Tri-State like Z80's data & address pins.
Some are Input only like Z80's INT pin
Some are Open collector

It would not be a bad Idea to color code the pin on the drawing you are working from. If you use chip labels, color code those also.

This way you will easily be able to see that you are not connecting one output to another output, ground or +5v

A chip could be still working, but in general I think the more stress you put on a chip the shorter it's life.

 Now looking at old SIO datasheet
Low level output  0.4v @ 1.8ma  later datasheet 2.0ma  this is for NMOS SIO
  The cmos SIO lists 2.0 ma

[nockieboy]

Hint for breadbord
  don't go over chips.

Yeah, I was trying to avoid that at the start, but towards the end I was running low on the right colour wire, so cut corners (literally.)

Will get to testing the connections later today hopefully and get the scope on it at some point over the weekend.  Was considering the practicalities of re-writing the monitor program so that it didn't use interrupts to read input and see if it worked, as it seems everything is pointing to an issue with the INT signal not working correctly.

[PA0PBZ]

Was considering the practicalities of re-writing the monitor program so that it didn't use interrupts to read input and see if it worked, as it seems everything is pointing to an issue with the INT signal not working correctly.

Please don't. We will have to assume for now that Grant's software is working and that you have a hardware problem. If you now introduce new software then we have another suspect...

[C]

Keep checking back using Grant's UN-modified code in case there is an error in your code changes.

When trying to find a problem, you should not add more possible problems.

When you have a working system, you can make small changes and see if those changes created a problem.

Grant's design is all working or no help.
No test software for hardware, No feedback until most of circuit is working.
A low chip count was more important then a good system that can grow or your time when there was problems.

While adding the ROM to Z80, you should have been adding a simple 8-bit output port connected to LEDs.  You could then have had feedback that should just work 
Next an 8-bit input port so that you can talk to program and have program change what it is doing.
Then RAM
Only then add the SIO
  Was a big fail to even try connecting a over clocked 68B50 to a Z80. But to then rip it out and put in a SIO to progress is even bigger fail. At a min it should have been add the SIO to existing 68B50, test SIO is working and then and only then remove the 68B50. This change cost you big time as you lost all feedback again from Z80.

So keep it simple
  Match Grant's circuit
  Use Grants's software

When it's working then you can make it better.

[nockieboy]

  Was a big fail to even try connecting a over clocked 68B50 to a Z80. But to then rip it out and put in a SIO to progress is even bigger fail. At a min it should have been add the SIO to existing 68B50, test SIO is working and then and only then remove the 68B50. This change cost you big time as you lost all feedback again from Z80.

So keep it simple
  Match Grant's circuit
  Use Grants's software

When it's working then you can make it better.

Just to be clear, this SBC is entirely different from the first one with the 68B50 (which still works perfectly - overclocked or not - and has allowed me to learn a lot about Z80 assembly while I've been modifying the BASIC and monitor code.)

Okay, I'll check and re-check the connections.  Once I've done that, I'll see if the oscilloscope shows any activity on the INT line.  If that's still dead, I'll replace the SIO/2 with the backup and see if that clears the problem.  If not, I'll swap the Z80 out as well (in case the INT on the CPU has been damaged too.)

That's my plan of action - let me know if there's things I should be considering inbetween any of those steps.

EDIT:  Just a thought - I'm looking for a low pulse on the INT line.  If I hold down SPACE on the computer whilst the SBC is waiting for input on ports A & B, then I should see some sort of repeating pattern on the INT line, presumably?

[PA0PBZ]

EDIT:  Just a thought - I'm looking for a low pulse on the INT line.  If I hold down SPACE on the computer whilst the SBC is waiting for input on ports A & B, then I should see some sort of repeating pattern on the INT line, presumably?

Yes, set the scope to negative slope trigger and the trigger around TTL/2 (2V will be ok)

[C]

Load Grant's original code
Then yes you should see a low pulse on the INT line for each character sent from PC.. The upper limit for a Logic Low input is 0.8v for Z80. The SIO outputs a logic low around 0.4v @ a load of 1.8ma.
If you see higher levels then 0.8v for a  low then SIO INT pin is Bad.
The SIO_INT pin is open drain, It can only pull output low, the resistor pulls output high.
 

You should also see
USB_Tx going high & low, both at the USB_Tx Pin and at the SIO_Rx pin. The amount of level change should be greater then 2.4v and should be around 4v.
If you look at SIO_Tx pin while Z80 is sending The level change should close to what you see on USB_Tx..
When looking at the bit times on scope, USB_TX & SIO_TX should be very close to same width.

If you do NOT see level changes on USB_TX when sending characters from PC then look at level on USB_CTS, should be low and go high only if Z80 program is not reading characters out of interrupt buffer fast enough..

[nockieboy]

I'm not really sure my oscilloscope (or my knowledge of how to use the scope) is up to this task, but with a little perseverance I think I'm interpreting the poor results correctly.  The INT line is high, CTSA and RTSA are low and, whilst I can't get a stable trace on the oscilloscope, the trace is disappearing on RxDA when I hold down the spacebar or briefly disappearing on TxDA when I reset the SBC (and it transmits the 'press space..' string).  That seems to indicate that data is being received at the SIO (I know it's being transmitted from the SIO as I get the initial 'press space...' string in the terminal window.)

The INT line, however, remains permanently high.  I've tried a variety of voltage ranges, time bases and trigger level/slope settings, but I can't get anything on the INT line other than the high voltage.  Unless anyone has any other suggestions, it looks like I've got to consider the possibility that the SIO can no longer pull the INT line low due to damage from having a 470R resistor on it previously.

I've also checked the connections and can find no further faults.

So my next step is to replace the SIO, unless anyone suggests anything else?

[PA0PBZ]

What model scope is it? Do you know the difference between continuous and single shot mode?

[C]

Scope

set scope to free run, You have a trace showing.
When you touch your scope probe  to a ground connection on Z80. The trace should change little. this is your ground refference 0v. this is the min of a signal.

Touch you scope probe to 5v connection.  this is max of a signal.

Now adjust voltage range on scope so that both levels stay on screen
At 2v setting the above two levels should change 2.5 grids in vertical direction. Use vertical position to move what you see in vertical direction.

If you have this then when you look on TxDA or RxDA you should see the top and bottom  of trace.  Horizonal time base lets you addjust time so that sizes increases.

The trigger
    You pick direction and level.  When level is above or below signal you have a trace.  when between then direction selects which edge starts trace.

 
From what you are stating
   replace SIO

[nockieboy]

What model scope is it? Do you know the difference between continuous and single shot mode?

It's a Hitachi V-212 - quite an old 'scope I think.  Has a knob to adjust the trigger slope, not sure about continuous or single shot selector though...? Don't think it has that feature.  I did read, however, an interesting tidbit about the sweep and triggering - looks like I may have had it in NORMAL mode as the sweep disappeared when there was a signal I thought should have triggered the scope.  Will get it back out tomorrow and take another look.  In any case, can't see anything that would cause the INT line not to show a repeating LOW signal.. 

From what you are stating
   replace SIO

Yes C, I think that's the next step.  I have the backup out already. 

[PA0PBZ]

I think it is this one?



First adjust your vertical scale like C suggested.
When you set the MODE switch to auto it will always show a trace, but if you set it to normal then it will only show a trace if the trigger condition is met.
If you are looking at the INT line you are looking for a downwards going slope, so pull the LEVEL switch out. Now if you hook it up to the INT line, send spaces and slowly turn the LEVEL switch you should see a trace whenever the SIO receives a character and pulls the INT line down. Set the TIME/DIV around 1mS so you wont miss the trace, and if it starts working then you can decrease the time to make the pulse visible.

If this fails then one last thing you can try is remove the INT wire from the processor, make sure there is a pull up resistor on the INT line and try again. If you still don't see anything prepare to replace the SIO.

[PA0PBZ]

In any case, can't see anything that would cause the INT line not to show a repeating LOW signal.. 

It is a very short pulse, and with the scope in auto mode you will likely miss it. That is where the normal mode comes in, every time the scope is triggered you will see a trace.
You can practice by using a pull up to +5V and then a push switch to ground. Connect the scope to where the switch is connected to the pull up. This point is normally 5V but will go to zero when you press the switch, so that is the point where you want to see a (single) trace on the scope. Start with a slow time base like .1 second.