Z80 Homebrew Computer - fault finding

[C]

After doing what PA0PBZ says with switch

With scope connected to look at the received spaces.
you should see no trace until you send a space

Check INT again

Then If you want to play some

You could replace the 4k7 with a much higher value
10k 20k
See if you get a twitch on INT
Transistor of output might not be total gone and work under very low load.
Remember that   Z80 INT pin is a load like the resistor.

[C]

V-211 V-212 Operation Manual.pdf
https://mpe.berklee.edu/documents/studio/manuals/testingmet/Hitachi%20V212/V-211%20V-212%20Operation%20Manual.pdf


In case you do not have it.

[nockieboy]

Thanks for the advice guys - I'm struggling to get much done at the moment as I only have brief periods of time I can look at this, which is making it much harder to progress.

I did swap out the SIO for the spare this morning, however.  Exactly the same problem - shows the initial message on cold reset, but doesn't seem to be accepting input (or it's not pulling INT low enough...)

I think maybe more resistance for the INT pullup is required as C has suggested - maybe swap the 4K7 for a 10K?  I'll get the scope out again next and do some more examination of the INT line - thanks for the help with that, PA0PBZ. 


EDIT:  Swapped the 4K7 pullup on the INT line for a 10K resistor.  Still no change.  Will see if I can get some more detailed testing done on the INT line later today with the oscilloscope...

[nockieboy]

Okay, after a little more testing with the oscilloscope, I've got the following to report:

USB Tx line seems to be just under 4 volts when nothing is being transmitted/received.
USB Rx line seems to be just under 4 volts when nothing is being transmitted/received.
USB CTS is low (0v or as close as.)
USB RTS is low (ditto.)

I know the USB Rx line is working as I'm getting the initial 'press spacebar to continue' message, but just to make doubly sure I tested the line with the scope and can briefly see the low pulses of the data being transmitted to the terminal to display the initial text.

When I cold-reset the SBC and get the prompt to press the space bar, I hold the space bar down and monitor the USB Tx line (and later also the SIO's RxDA pin).  After some fiddling with controls on the scope, I'm getting signs of life on the USB Tx line - there's a definite low pulse, although I can't get a stable trace I can see for sure that there is a repeating low pulse on the USB Tx line (and at the SIO's RxDA pin.)

So, data is definitely reaching the SIO's RxDA pin.

Next to test is in the INT line.  I've tried this with the scope connected directly to the SIO INT pin.  There appears to be a lot of noise on the line - I'm not getting a clean trace even at the lowest time/div setting, it's blurry - seems to oscillating at a very high frequency (>20MHz as that's the fastest my scope will go) between 4 and 5 volts.  Holding down the space bar whilst the SBC is awaiting input is not causing any change in this trace whatsoever - even if I was unable to get a good trigger, I'd still see the line flicker with the repeated LOWs on the INT line as the character buffer fills.

Remember, this is the second SIO - not the first one where I had the 470R resistor pulling INT high.  Should I consider looking at the Z80?  Maybe it has an issue with INT at its end?

[nockieboy]

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.

Just tried this with the 10K pull up resistor - still lots of noise on the line, but got a solid trace on the noise this time!  It's obviously picking up signals from other wires.

More importantly, INT didn't go LOW at all, despite the space bar being held down...

What are the chances both SIO's are faulty? (They were obtained from eBay...)

[C]

Both sio bad, possible.

Wrong software could be cause of no Z80 INT
This has to be programmed to happen.
Just to be safe, you might want to load ROM with a new copy of Grant's software.
From what I read this is ROM.HEX

One thing you said
Sounds like you have a bad USB_TX

You should not need to make any changes to scope when you shift the probe from USB_TX to USB_RX or SIO_RX to SIO_TX
The bit time of signals should be same
The voltage change should be close, you should see on scope no problem

Only trigger level might need changed nothing else.
 

[nockieboy]

One thing you said
Sounds like you have a bad USB_TX

You should not need to make any changes to scope when you shift the probe from USB_TX to USB_RX or SIO_RX to SIO_TX
The bit time of signals should be same
The voltage change should be close, you should see on scope no problem

Only trigger level might need changed nothing else.

Was struggling to understand what you meant here, but realised it was because of how I wrote my previous post. The paragraph about testing the Tx line was originally before the one about testing Rx, but I swapped them round. So the fiddling to get a trace was the first thing I did and I didn't have to change anything to view the Tx line. Sorry about that!

I've ordered a couple more SIOs, 8MHz ones, in case that's the problem. If it's not, they're still more compatible I guess.

[C]

Serial
  With async serial which is what you are using, The stop bit is same level as when nothing is being sent. The Start bit is the other level and when held at this level is a special condition called BREAK and is used to get attention of receiver.
I say it this way as you find the levels reversed at some points when testing serial, the driver chips that put SIO signals on long cable are inverters.

Now the SIO is being set for 8N1 this means you have 10 bits for each character. The start bit(always low), 8 data bits, Stop bit(always high).

Depending on how the serial port is programmed each character or chunk of data could have between 7 bits to 12 bits. Data field could be between 5 to 8 bits. The stop bit has an option to be two bits wide. And you have option of adding a parity bit.
Here you are using the common 8N1, 8 data bits, no parity & one stop bit.

On your scope you could have a any amount of bit time showing.
A space could take any amount of with of screen. Almost full screen with is fine. You adjust this with time base of scope.

What you care about is the width of the bits is close to the same when you shift from looking at Tx to Rx  Close here is 1% difference or so, If you see a difference there could be a problem.

Second thing is Voltage levels you see on scope.
The Z80 uses 5 volt logic. If you set the vertical controls of scope such that with DC coupled input, 5v and 0v are on screen you should not need to change vertical settings.
Keep in mind that 0.8v us max voltage you can have for a logic 0 at an input.
Having A 0V to 5v change on scope while needing to see if parts are less that  0.8v suggests using 5 grids with a need to know where 0v is. So Adjust vertical position so trace is on a grid when touching probe tip to a ground on Z80 circuit. 
 
Now if you connect scope to SIO_Tx then you should see signal changes during message. 
The Tx output wants signal low to be less than 0.8v at detestation, so it tries to output 0.4v or less for a logic 0.
The Tx output wants signal High to be greater than 2.2v at detestation, so it tries to output 2.4v or more for a logic 1.

The voltages can be different for different chips
You will find the exact limits when looking at datasheet
VIH Input High Voltage = ____    The 2.2v above
VIL Input Low Voltage = ____   The 0.8v above
VOH Output High Voltage =_____  the 2.4v above
VOL Output Low Voltage = _____   the 0.4v above
Note that load currents can change the levels and Capacitance can change the speed of change.


So with all the above in mind
You should see little difference between
USB_Tx, USB_Rx, SIO_Tx & SIO_Rx

If you are seeing a difference, then there could be a problem.
Noise is not a problem unless it causes a noise change past input levels.
 
Wrote above before last post.


One additional bit of test Information
IEO should go low while interrupt in SIO is pending and back high after service.

So If I am reading you latest posts
All Tx & Rx signals are changing as listed above & You see no logic low on the Z80 INT pin.

[C]

Starting with strait from Grant's ROM.HEX is important step to try.
Software not setting SIO for interrupt mode could stop INT output.

Note that you might not see INT great with out changing some settings on scope, But if you only see a trace when space is sent from PC, Then with same settings when connected to INT you should get a trace on screen for each Low on INT.
INT is a to LOW transition sane as Start bit.
IEO is also a to LOW transition.
 

What is labeled on the two SIO chips that you have?

Just to be complete what is labeled on your Z80 CPU's?


 

[PA0PBZ]

@nockieboy

Play with your scope, this will be a good learning experience not only for fault finding in this sbc but also for the future.

Did you try the experiment with the switch? Did you see the difference between normal and auto mode?
Next, try to adjust the scope so that 1V is 1 vertical division and then monitor the data that comes out of the USB TX line.
Set your scope to normal mode and make it trigger on the start bit.
Now adjust the timebase to have 1 bit per division, use TIME/DIV and SWP VAR for this. Does the setting make sense for the baud rate you are using?
If you succeed you will see that you can decode the ASCII characters by just looking at the scope and see which bits are high and which are low.

I think being able to do the above and know what you are doing is essential for debugging these kind of problems, so please invest some time in this.

[nockieboy]

Starting with strait from Grant's ROM.HEX is important step to try.
Software not setting SIO for interrupt mode could stop INT output.

Note that you might not see INT great with out changing some settings on scope, But if you only see a trace when space is sent from PC, Then with same settings when connected to INT you should get a trace on screen for each Low on INT.
INT is a to LOW transition sane as Start bit.
IEO is also a to LOW transition.
 

What is labeled on the two SIO chips that you have?

Just to be complete what is labeled on your Z80 CPU's?

I'm using the original monitor code, unchanged, from Grant's website.

The SIOs I've been using are marked Z8442B1 - I think these are original 80's fab chips, designed for 2.5MHz operation.  Not sure if that is important as Grant Searle doesn't seem concerned about overclocking the chips in his SBC designs, but they're NMOS rather than CMOS chips so I'm wondering if there's an incompatibility caused by the system clock speed or levels?  The chips are Tx-ing data to the serial terminal with no issues, though.

The CPU is a Zilog Z84C0008PEG.

Anyway, I've ordered a couple of Z84C42008PECs, CMOS 8MHz SIO/2s - hopefully these will work!

[C]

You see a lot of big trucks running down the road at the speed limit. Most have to slow down when the load gets to great. Now how many can even get to a speed that is 25% greater then the speed limit? Here you are asking a chip to work at 3 times it's datasheet speed.

At some point the digital electronics can not change from one state to the other fast enough before  being commanded to change back. At the extreme you have a signal that never gets to an amplitude to change states. This increased speed normally results in more heat, heat that can shorten the life of the chip.
Digital you want perfect, one error in a billion can be a huge error.

In most logic there are slow spots where the logic is just fast enough to function properly. When you speed up the clock these areas no longer function correctly.
In old logic it is not unusual to see one or more chips of a different logic family just for this reason and even then be critical.


I would think that the serial transmit is the simple logic area of the chip. Each other area takes more logic and has stricter time requirements.

Think of ZILOG
If Zilog could have proved the chip worked at a higher speed, why would they not state this fact. It took some time for ZILOG to get a working set of chips for 4Mhz and again more time to get 6Mhz.
If ZILOG could have produced 8Mhz chips earlier then  there was no need for 6Mhz set

Now like most chips, the chip is a black box. You have no idea what part is the slow area. The next mask used to build the chips could have a different slow area. Just a different MFR can make a huge difference.

 So you have wasted a lot of time trying to use a chip out of speck. Worse would have been it worked part of the time, like trashing one received character out of thousands received.

While waiting for proper chips, I would strongly suggest following PA0PBZ and learn all you can about your scope. This will pay off big time in long run.

[nockieboy]

Okay, brief update.  The Z84C4208PECs (replacement 8MHz SIO/2s) arrived today and I've plugged the first one into the SBC in place of the old SIO/2 that was there and... it works!

Just goes to show - I needed to be a little more careful with the parts I chose for the SBC.  Was a strange problem with Tx on the SBC working but Rx not, but as you said C it would appear that the receive circuits are more complicated and couldn't keep up with the 7MHz clock.

Thank you so much for your time and patience, C and PA0PBZ! 

[PA0PBZ]

Congrats that you got it working finally, so now it's time for a mark 3 version? 

Oh, and don't forget to play with your scope!

[C]

While it is semi fresh in your mind, would not be a bad idea to use your scope and look at the signals.

You had INT that did not work, but you had the Z80 reading from that SIO chip. I would think you might see a difference when looking at the Data pins.
When Z80 talks to SIO I would expect that the logic level changes are fast. When the SIO talks back, The old SIO could be slower and delayed more then the new SIO.
Where before you saw two signal shapes on a data line, now you have something that matches better between read and write on data line.

[nockieboy]

Congrats that you got it working finally, so now it's time for a mark 3 version? 

Oh, and don't forget to play with your scope!

Haha! Not quite - next is to get the CF card storage up and running so I can load CP/M...  When (if!) that's done, I've got an AY-3-8912 I want to connect up and get some sound and IO going. 

I will definitely spend some time with the scope thought to get more competent with it! Thanks again for your help. 

[nockieboy]

While it is semi fresh in your mind, would not be a bad idea to use your scope and look at the signals.

You had INT that did not work, but you had the Z80 reading from that SIO chip. I would think you might see a difference when looking at the Data pins.
When Z80 talks to SIO I would expect that the logic level changes are fast. When the SIO talks back, The old SIO could be slower and delayed more then the new SIO.
Where before you saw two signal shapes on a data line, now you have something that matches better between read and write on data line.

I've got two 2.5MHz SIO/2s with no particular use at the moment, so I think some experimentation and scope practice is called for with them.  Thanks for your help C. 

[C]

Forgot to say

Congrats on it working.

Now that it is working, What things do you want to do or add?

 

[nockieboy]

Forgot to say

Congrats on it working.

Now that it is working, What things do you want to do or add?

Thanks. Well, the next thing to get working is the CompactFlash drive - I'd completely left it off the SBC until I knew it was working properly (which it now is!)

I'm using a 40-pin IDE to breakout adaptor with a CF card adaptor plugged into it. I've just been working out which pins on the CF card map to which pins on the breadboard. Next step is to wire it up as per the schematic and hope it works...

After that (and I've no doubt there'll be huge problems getting it to work - Grant Searle indicates that wire length can be critical in getting certain cards to work) the next thing I want to get working is the AY-3-8912 chip, for sound and IO. That'll require more software effort than hardware I'm thinking, but there's libraries I've found that I'll be able to tweak to work with my setup.

EDIT:

Also, I'm keen to learn how to setup an I2C interface from the spare port on the SIO (perhaps) so I can connect up more things.

[C]

After that (and I've no doubt there'll be huge problems getting it to work - Grant Searle indicates that wire length can be critical in getting certain cards to work)

I think I would connect wires direct to chip that outputs or inputs data from CF card.
For example CF D0-D7 & A0-A3 connect at Z80 chip.
Some separation of control signals would also be good.
One thing that helps when using ribbon cable is to have a ground wire between each control signal.
Note that you have a bunch of grounds on CF end A3 to A10, On ribbon cable, these would be between each signal on lower side of the connector.
This cuts out some cross talk between signals.

Am I making sense?

 

[nockieboy]

After that (and I've no doubt there'll be huge problems getting it to work - Grant Searle indicates that wire length can be critical in getting certain cards to work)

I think I would connect wires direct to chip that outputs or inputs data from CF card.
For example CF D0-D7 & A0-A3 connect at Z80 chip.
Some separation of control signals would also be good.
One thing that helps when using ribbon cable is to have a ground wire between each control signal.
Note that you have a bunch of grounds on CF end A3 to A10, On ribbon cable, these would be between each signal on lower side of the connector.
This cuts out some cross talk between signals.

Am I making sense?

You are. I'm not using any ribbon cable though - I'll post a pic of the setup when I'm in front of a computer, but I've got a CF card adapter plugged into an IDE-breadboard adapter (says it's an Arduino IDE breakout adapter) - it's also right next to the CPU on the SBC, so I'll be doing as you've suggested and using minimum-length wires to connect direct to the Z80.

I've also got some microSD adapters that connect via SPI. Was wondering if I can't get the CF drive working maybe I could set up an SPI bus somehow and use a MicroSD card instead. Have been having trouble finding detailed guidance on setting up SPI or I2C with a Z80 SBC though.

EDIT:  Pics of what I'm using for the CF card:

[C]

CF 

I've also got some microSD adapters that connect via SPI. Was wondering if I can't get the CF drive working maybe I could set up an SPI bus somehow and use a MicroSD card instead. Have been having trouble finding detailed guidance on setting up SPI or I2C with a Z80 SBC though.

One big difference between a microcomputer or microprocessor and a micro-controller is how IO is done. To keep software overhead low you add hardware while on micro-controller you might bit-bang.

Using simple chips you might have a 74xx374 as an output port. In the process of writing to 74xx374 you can easily create a Data strobe or new data signal so what is connected knows when new data exists. Micro-controller you software bit-bang a pin.
Getting to the point, I have seen a circuit for SPI, but it's been a while. Think it was 5 or 6 chips. For Z80 SPI is two chips (parallel in- serial out & serial in - parallel out) with some control logic.
Think I2C would be harder in hardware.

Think the best way would be to connect a micro-controller to Z80 to get some new things like SPI 7 I2C. Might want to look at
https://www.eevblog.com/forum/microcontrollers/help!-how-to-make-a-nsc800-computer/msg1243666/#msg1243666
Way back the parallel SCSI bus was used to connect computers & IO. Not hard to do in simple hardware and software can be easy. One of my Z80s has only 256 bytes of rom & the SCSI boot is in that rom along with many types & sizes of floppy boot.
Go extreme, put a SCSI interface on both of your Z80's and on a micro-controller and all can talk.

So many ways to do great hardware that has low impact on software speed.

[nockieboy]

Getting to the point, I have seen a circuit for SPI, but it's been a while. Think it was 5 or 6 chips. For Z80 SPI is two chips (parallel in- serial out & serial in - parallel out) with some control logic.
Think I2C would be harder in hardware.

So a 74HCT165 and a 74HCT164 would be suitable for that?  Hmm.. Well, the SPI seems the better option as I have a couple of bits that use it - a clock module, the microSD card adapters etc.  Seems that's the way to go with it.  I'll start looking into it in more detail once I've sorted the CF drive (or not, as the case may very well be.)

Err.. just had a thought though - wouldn't the SIO do the job of both the chips mentioned above?  It DOES do parallel to serial (Tx) and serial to parallel (Rx) quite well!

[C]

For SPI you just have 8 data bits, SIO adds a start & stop bit.

Z80 Write 8-bits to 74HCT165 serial out is SPI out
Write causes 8 clocks  on SCK & causes interrupt or status flag after 8 clocks

SPi In to serial input of 74HCT164 & serial input of 74HCT165
Z80 can Read 8-bits from 74HCT164

Now if you look at a micro-controller interface, You can chose to invert or not the clock & data.
For this you need a XOR chip.

The above is for a MASTER
For SLAVE SCK is input and clocks both chips.

Need a few more minor details.

[nockieboy]

For SPI you just have 8 data bits, SIO adds a start & stop bit.

Z80 Write 8-bits to 74HCT165 serial out is SPI out
Write causes 8 clocks  on SCK & causes interrupt or status flag after 8 clocks

SPi In to serial input of 74HCT164 & serial input of 74HCT165
Z80 can Read 8-bits from 74HCT164

Now if you look at a micro-controller interface, You can chose to invert or not the clock & data.
For this you need a XOR chip.

The above is for a MASTER
For SLAVE SCK is input and clocks both chips.

Need a few more minor details.

Okay - have been looking around the usual suppliers I have access to and found this:

http://uk.farnell.com/microchip/mcp23s08-e-p/8bit-expander-i-o-spi-i-f-dip18/dp/1332091

Would the MCP23S08 be any use with a Z80 SBC to create an SPI interface with minimal programming, I wonder?

Then there's this one:

http://uk.farnell.com/microchip/mcp23s09-e-p/ic-i-o-expander-8bit-spi-18dip/dp/1699843

It's an MCP23S09, major difference from the '08 is that it has open drain I/O pins...  Not sure which would be more appropriate, or even if they'd be any use at all instead of bit-banging through 74HCT165/4's?