Z80 Homebrew Computer - fault finding

[nockieboy]

Thanks C. Yeah I wasn't sure about the interrupt routine so thought it best to leave it, but I'll strip it out if it's definitely not needed.  The only thing that is different with my SBC from Grant Searle's design so far is that I haven't connected up the CF card adapter yet (and I haven't wired up the SIO/2's B port to an RS232 interface as I won't be using that.)

[nockieboy]

Okay, back after a week or two hiatus which has done loads for my sun tan, but very little for progress on sorting out the issue with my V.2 SBC...

I'm starting to lose my way a little in debugging this contraption.  Finding the time (and space) to get the oscilloscope out isn't easy.  Still, I've managed to strip the monitor code down to what I think is the bare minimum.  I know literally the square root of diddly squat about interrupts, but have (I think) correctly removed the interrupt from the monitor code and simplified it as far as I can. 

I've even removed the SIO B port setup and references (and before anyone asks, the FT232 is definitely wired to the A port on the SIO/2!) 

Would appreciate an experienced eye to scan over the test monitor code that I intend to use below.  Before I went on holiday I did a quick test with the oscilloscope on the HCT138 output that selects the SIO/2, but wasn't getting very clear readings.    So I'd be really grateful if someone could confirm that the code below will/should work and be suitable for creating a trace I can use to debug the circuit.

Here's the monitor code:

Code: [Select]

;------------------------------------------------------------------------------
;
; SIO Serial Test ROM
;
;------------------------------------------------------------------------------

CR .EQU 0DH
LF .EQU 0AH
ESC .EQU 1BH
CTRLC .EQU 03H
CLS .EQU 0CH

SER_BUFSIZE .EQU 40H
SER_FULLSIZE .EQU 30H
SER_EMPTYSIZE .EQU 5

RTS_HIGH .EQU 0E8H
RTS_LOW .EQU 0EAH

SIOA_D .EQU $00
SIOA_C .EQU $02

.ORG $4000
serABuf .ds SER_BUFSIZE
serAInPtr .ds 2
serARdPtr .ds 2
serABufUsed .ds 1

primaryIO .ds 1
secNo .ds 1
dmaAddr .ds 2

stackSpace .ds 32
STACK    .EQU    $ ; Stack top


MON .ORG $0000 ; MONITOR ROM RESET VECTOR
;------------------------------------------------------------------------------
; Reset
;------------------------------------------------------------------------------
RST00 DI ;Disable INTerrupts
JP INIT ;Initialize Hardware and go
NOP
NOP
NOP
NOP

;------------------------------------------------------------------------------
; Initialise hardware and start main loop
;------------------------------------------------------------------------------
INIT LD    SP,STACK ; Set the Stack Pointer

LD HL,serABuf
LD (serAInPtr),HL
LD (serARdPtr),HL

XOR A ;0 to accumulator
LD (serABufUsed),A

; Initialise SIO A
LD A,$00
OUT (SIOA_C),A
LD A,$18
OUT (SIOA_C),A

LD A,$04
OUT (SIOA_C),A
LD A,$C4
OUT (SIOA_C),A

LD A,$01
OUT (SIOA_C),A
LD A,$18
OUT (SIOA_C),A

LD A,$03
OUT (SIOA_C),A
LD A,$E1
OUT (SIOA_C),A

LD A,$05
OUT (SIOA_C),A
LD A,RTS_LOW
OUT (SIOA_C),A

; Debug routine to test serial interface
DBG: LD A,'U'
PUSH AF
conout: OUT ($08),1 ; DEBUG TRIGGER FOR Y1 PIN ON 74HCT138
OUT ($08),0 ; Clear the debug trigger
SUB A ; Check to see not TXing
OUT (SIOA_C),A
IN    A,(SIOA_C) ; Status byte D2=TX Buff Empty, D0=RX char ready
RRCA ; Rotates RX status into Carry Flag,
BIT  1,A ; Set Zero flag if still transmitting character
JR Z,conout ; Loop until SIO flag signals ready
POP AF ; RETrieve character
OUT (SIOA_D),A ; OUTput the character
JP DBG

FINIS .END

Any help/advice is always greatly appreciated - I don't have to experience to sort this myself, unfortunately.  One line in the code above is vexing me somewhat though - not sure if it's a typo I've created or carried over from the original source.

Code: [Select]

STACK    .EQU    $ ; Stack top
Is that valid assembly?

Thanks in advance.  My next step is to write this code to the ROM and hook up the oscilloscope and see if I can get some traces that might aid in diagnosing the problem.  If that doesn't work, I'm likely to rip the SIO/2 off the breadboard entirely and replace it with a 68B50 as used in the V1 SBC that started this thread.  With a little monitor code rewriting, should be able to get that up and running and see if it is really the SIO that's the problem.

[grumpydoc]

Any help/advice is always greatly appreciated - I don't have to experience to sort this myself, unfortunately.  One line in the code above is vexing me somewhat though - not sure if it's a typo I've created or carried over from the original source.

Code: [Select]

STACK    .EQU    $ ; Stack top
Is that valid assembly?

Yes '$' means 'current address'

So

stackSpace   .ds     32
STACK        .EQU    $      ; Stack top


Means reserve 32 bytes for the stack and define the symbol STACK to be the address just after that space (which is what you need to load the stack pointer with initially).

[C]

Just a quick look at your code

Code: [Select]

; Initialise SIO A
   LD  A,$00
   OUT  (SIOA_C),A ; select regester 0
   LD  A,$18 ; D3 D4  command 3
   OUT  (SIOA_C),A ; Command 3 ( Channel Reset )

   LD  A,$04
   OUT  (SIOA_C),A ; select regester 4
   LD  A,$C4 ; 0b11 00 01 0 0
                        ; D2 + D3 1 Stop bit
                        ; D6 + D7 X64 clock mode
   OUT  (SIOA_C),A

   LD  A,$01
   OUT  (SIOA_C),A ; select regester 1
   LD  A,$18 ; 0b11000
; D3 + D4 INT on all RX
   OUT  (SIOA_C),A

   LD  A,$03
   OUT  (SIOA_C),A ; select regester 3
   LD  A,$E1 ; 0b11 100001
  ; D0 RX enable
  ; D5 Auto enable
  ; D6 + D7 Rx 8 bits char
   OUT  (SIOA_C),A

   LD  A,$05
   OUT  (SIOA_C),A ; select register 5
   LD  A,RTS_LOW ; RTS_LOW  .EQU 0EAH  0b11101010
                        ; D1 RTS
                        ; D3 Tx Enable
                        ; D5 + D6 Tx 8 bits char
                        ; D7 DTR
   OUT  (SIOA_C),A
 
For simple testing, I would want simple polled mode for send and receive. This means that before transmitting a character you make sure that the transmitter output is empty before character output ( looks like your test code is doing this.
For receive you would check if there is received  character before reading the character.

When your simple SIO output code is working, I would modify a copy of the test code to just echo received character to the output. Then you should see what you type on the PC echoed back to PC. A simple step.

=======
For SIO register 1 you are enabling Rx interrupts.
Might not matter when Z80 has disabled interrupts, but?

Then for SIO register 3 you have  D5 Auto enable
This enables DCD & CTS to control receive and transmit enables. You will not transmit(CTS) or receive(DCD) unless the pin is low
Make sure that Z80 SIO pins 18,19 & 31 are all connected to gnd.
If you change this setting then 18 & 19 are just status bits in SIO register..

Just to summarize your code
  .ORG $4000 should be RAM
  .ORG $0000 should be ROM

  SIO A data register is at I/O address $00
  SIO A command register is at I/O address $02

  DTR & RTS pins should go low when you write to  SIO register 5 and stay low

Now this is not an easy design to test. The way the 74LS138 is currently connected only an address match is needed to make an output to go low. A read or write to memory of address range of XX00 to XX07 will also cause 138's pin 15 to go low for that memory access.
You do not have to have complete address decode for a computer to function. Said a different way now you should have many Address What SIO will respond to (SIO CS pin goes low)

$00  SIO A data register
$01 SIO A command register
$02  SIO B data register
$03 SIO B command register
$04  SIO A data register
$05 SIO A command register
$06  SIO B data register
$07 SIO B command register

To make testing easer I would make a change to 138's connections.
If you were to connect Pin 5 to Z80 IORQ instead of A7 then the outputs of the 138 would only go low for valid I/O access. The side effect is that more I/O addresses will cause a output to go low, but this is not a problem.
After change with the SIO connected to 138's pin 15 like now, the SIO could be accessed from some additional addresses, but you gain a great output to trigger your scope.
After the change the Address what SIO will respond to (SIO CS pin goes low)
I/O $00  SIO A data register
I/O $01 SIO A command register
I/O $02  SIO B data register
I/O $03 SIO B command register
I/O $04  SIO A data register
I/O $05 SIO A command register
I/O $06  SIO B data register
I/O $07 SIO B command register

I/O $80  SIO A data register
I/O $81 SIO A command register
I/O $82  SIO B data register
I/O $83 SIO B command register
I/O $84  SIO A data register
I/O $85 SIO A command register
I/O $86  SIO B data register
I/O $87 SIO B command register

The code should work fine.

After this change OUT  ($08),x will cause 74ls138's pin 14 go low for a short time while the instruction is executed. The actual data does not matter. Your current code will cause two short low outputs. I would remove the second.
 
If you add a
OUT ($20) just before the POP AF then you will get a short low on 138's pin 12 just before sending a character to output register.

Note:
Don't rip out the SIO if you go back to 68B50. Add it to what you have so you could use it to test and get the SIO working. If the SIO's CS pin is high then it's the equal of NOT THERE.

[nockieboy]

Thanks C - just to let you know, I've not given up on the project yet (or fixed it either!) I've just been away on holiday and busy since I got back. 

I've had an hour or so tonight to take another look, made some changes to the code, but still not getting a stable trigger on a clean trace - the processor just isn't following a short enough loop to display on my 'scope.

I like the idea of linking the IORQ to the '138 though - don't know why it wasn't done in the original design tbh, but it's my next step.  If I really don't get anywhere with that, or your other suggestions, then I'll try linking in a 68B50 on another breadboard and hotwiring it into the SBC to see if I can get that to work.  At least I know for sure the 68B50 works.

[C]

Think of making it easy on your self to get this working.
A scope is not a logic analyzer,  need to use it as a scope if possible.

Where could be the problem?
1. SIO Chip you have will not function properly with this CPU clock input.
   What SIO chip do you have? Think the chance of a 2Mhz SIO  chip working properly at 400%+ clock speed is small.

2. Wrong or missing connections to SIO.
   One wrong connection and data to and from SIO chip is also all wrong.
   This is easy to check!!!
 Make a net list of connections ( this pin on this chip connects to this pin on this chip).
Start with ZILOG data and make your list.
For a few pins you will need to look at Grant's stuff to get more specific. B/a and C/D pins are examples of this.
Then check your list many ways against the hardware so that the chance of error becomes small.
Check from the medal of pin on one chip to medal of pin at other end.

3. test software

Code: [Select]

; Read SIO reg 0
; output scope trigger $08  (138 Y1)
out ($08),x
Test bit 5 (CTS) pin in SIO Status
Jr Z  SIO_Status_3
;lFor one level make 138 Y2 pulse low
out ($__),x 
SIO_Status_3:
Test bit 3 (DCD) pin in SIO Status
Jr Z  SIO_Status_2
;lFor one level make 138 Y3 pulse low
out ($__),x 
SIO_Status_2:
Test bit 2 (DCD) pin in SIO Status
Jr Z  SIO_Status_1
;lFor one level make 138 Y4 pulse low
out ($__),x 
SIO_Status_2:
Test bit 2 (Tx_Empty) pin in SIO Status
Jr Z  SIO_Status_1
;lFor one level make 138 Y5 pulse low
out ($__),x 
SIO_Status_1:
Test bit 1 (Int) pin in SIO Status
Jr Z  SIO_Status_0
;lFor one level make 138 Y6 pulse low
out ($__),x 
SIO_Status_0:
Test bit 0 (RX_char) pin in SIO Status
Jr Z  SIO_Status_done
;lFor one level make 138 Y7 pulse low NOTE REQUIRES CURRENT Y7 CONNECTION TO BE DISCONNECTED!!!
out ($__),x 
SIO_Status_done:

Think of what above code does.
Trigger scope with 138-Y1 and a short time later pulse on pin _ if that bit = _.
Each Status bit has a pin, you have a low or no low on 138 pin.

Two of the 138's outputs you can make pulse or not pulse by changing states of CTSA(pin 18) and DCDA(pin 19).
If you can not make this happen then problem most likely #1 or #2 above.

The time between pulse on Y1 to possible pulse on Y2 is short with time increasing to max delay of Y7 pulse.
If even this time is too much for your scope, then add a Y1 trigger output just before the JR instructions.

The SIO has some outputs you can control. Again a great way to test if you are talking properly with SIO chip.

[nockieboy]

Okay, quick progress update.  I've found some time to test the system (and specifically the FT232RL interface) and have made some major progress.

Firstly, I've discovered an intermittent problem with the FT232RL USB-TTL adaptor.  I've tested it on the v1 SBC and it works for a few minutes, before it seems to go crazy and either ignores key presses or spits out corrupted information, causing the SBC to crash.  It works fine with the USB-TTL lead that I normally use (which has an FT232 in it, strangely) so I'm wondering if there's an issue with the little adapters not being original FTDI chips?

Anyway, after re-wiring the serial end of the v2 SBC to take the USB-TTL lead, I am now able to power-on the SBC and get the initial message from the monitor - "Press [SPACE] to activate console"

The issue I'm having now is that no matter what I press, nothing else happens.  The SBC doesn't seem to be receiving data.

I've checked the USB-TTL lead in another breadboard by connecting RxD to TxD and getting what I type echoed back to the serial terminal, so the lead seems okay.  However, when I connect RxD to TxD directly on the v2 SBC board, I'm not getting any echoed characters at all.  I'm wondering if CTS/RTS is the issue?  I've tried setting up the terminal to ignore flow control entirely, but that makes no difference.

To be clear, I've checked the connections on the SIO - CTSA is connected to RTS on the USB-TTL lead, and RTSA is connected to CTS on the USB-TTL lead, RxDA to TXA and TxDA to RXA.  The SIO is clearly able to send data, as the initial monitor message is being displayed when the SBC is cold-reset, but for some reason I'm unable to send data to the SBC (or it's unable to read it.)

I've tried the serial terminal (PuTTY) with CTS/RTS flow control and with none, doesn't seem to make a difference.  The monitor program in ROM is identical, unchanged, from the Grant Searle code available on his website for the CP/M SBC.  Any ideas what else I can test or where I should be looking?

[PA0PBZ]

Do you still see the initial message if you connect RX and TX from the SBC together and leave the TX from the cable unconnected?

[nockieboy]

Do you still see the initial message if you connect RX and TX from the SBC together and leave the TX from the cable unconnected?

Yes, the message still appears. 

[PA0PBZ]

Next step: Do you see echo characters on the PC if you connect RX and TX from the cable together and leave the TX from the SBC unconnected?

[nockieboy]

Next step: Do you see echo characters on the PC if you connect RX and TX from the cable together and leave the TX from the SBC unconnected?

Yes, it's echoing correctly.

EDIT:

I'm just wondering if the correct serial port is being selected on the SIO?  Is there a chance it's receiving input on A, but selecting B as the main console interface by some mixup in the hardware or software selection?  The monitor program checks both A & B receivers for a space - when it receives one, it sets the variable primaryIO to $00 or $01 if it has received the space char on A or B respectively... What if it's receiving the input on A, but selecting B as the primary IO?  That would explain why nothing happens after the initial message perhaps?

[PA0PBZ]

I'm just wondering if the correct serial port is being selected on the SIO?  Is there a chance it's receiving input on A, but selecting B as the main console interface by some mixup in the hardware or software selection?  The monitor program checks both A & B receivers for a space - when it receives one, it sets the variable primaryIO to $00 or $01 if it has received the space char on A or B respectively... What if it's receiving the input on A, but selecting B as the primary IO?  That would explain why nothing happens after the initial message perhaps?

Are you sure that it receives anything?
Does it set primaryIO?
Can you output for instance hex 30 +primaryIO to both SIO's after it has been set?

[nockieboy]

Okay, I tweaked the conout: routine to ALWAYS print the output to BOTH A & B outputs, so whatever is printed to primaryIO will go to both serial ports no matter what.

Code: [Select]

;
------------------------------------------------------------------------------
; Console output routine
; Use the "primaryIO" flag to determine which output port to send a character.
;------------------------------------------------------------------------------
conout: ;PUSH AF ; Store character
;LD A,(primaryIO)
;CP 0
;JR NZ,conoutB1
;JR conoutA1
conoutA:
PUSH AF

conoutA1: CALL CKSIOA ; See if SIO channel A is finished transmitting
JR Z,conoutA1 ; Loop until SIO flag signals ready
POP AF ; RETrieve character
OUT (SIOA_D),A ; OUTput the character
;RET

conoutB:
PUSH AF

conoutB1: CALL CKSIOB ; See if SIO channel B is finished transmitting
JR Z,conoutB1 ; Loop until SIO flag signals ready
POP AF ; RETrieve character
OUT (SIOB_D),A ; OUTput the character
RET

So it shouldn't matter what primaryIO is set to, it should print the contents of the A-register to both serial ports.   I'm still not going any further than the initial message to press the spacebar.

I've also added in the suggested change to show what primaryIO is set to + 30H, here's the code below where the monitor waits for a spacebar press:

Code: [Select]

; Wait until space is in one of the buffers to determine the active console

waitForSpace:

CALL ckincharA
jr Z,notInA
LD A,$00
LD (primaryIO),A
CALL conin
CP ' '
JP NZ, waitForSpace
JR spacePressed

notInA:
CALL ckincharB
JR Z,waitForSpace
LD A,$01
LD (primaryIO),A
CALL conin
CP ' '
JP NZ, waitForSpace
JR spacePressed

spacePressed:

LD A,$30+primaryIO ; DEBUG
CALL conoutA ; DEBUG
CALL conoutB ; DEBUG

Still no further in getting it working though.  (I haven't yet tried the change to the last bit of code above to show primaryIO - I figure it's not necessary as the monitor should be sending to both serial ports anyway.)

[PA0PBZ]

Some thoughts:

Are both SIO's initialized?

Do you have scope (sorry, can't remember). If so, can you observe a change in pattern on the data/address lines when you press a space?

Is the full code you are using somewhere on the net?

[nockieboy]

Some thoughts:

Are both SIO's initialized?

Do you have scope (sorry, can't remember). If so, can you observe a change in pattern on the data/address lines when you press a space?

Is the full code you are using somewhere on the net?

Yes, both SIOs should be initialized.  Have a scope, but won't be able to check it for a day or so - will try your suggestion re: data/address lines as soon as possible.

Yes, the full code is available here:

http://searle.hostei.com/grant/cpm/z80sbcFiles.zip

The zip file contains everything for the CP/M SBC, but the file you're wanting to see is in /source/monitor.asm.

[PA0PBZ]

Are you using this monitor.asm file or are you using your stripped-down version? I read something about removing the interrupt routines but these are essential to receive characters.

[nockieboy]

I'm using the full monitor program as provided on Grant Searle's website and linked previously.

[PA0PBZ]

I'm using the full monitor program as provided on Grant Searle's website and linked previously.

Just checking...

Anyway, if you get the scope out also check the INT line for activity when you send a char to the sbc.

[C]

If you have two USB to serial connect both,
or
I would strap the unused Z80 SIO Rx input to a level if it's not already been done.

Test this.

If you are making changes to grants code, then make minor change to code so that the SIO port you want now is always selected.
If you are using port A then make space test always act like is received a space on port A and select A.

Thinking you may have noise being received on other port

[C]

Do not remember if you are using the MAX232 for second port.

Strap
If you are using RXDA for receive, then look at level on this pin with USB to serial adapter connected while not sending from PC.
This is not sending level, for serial when held to the other level it is a BREAK and the SIO will detect this.
Connect RXDB to this level if not connected to a powered USB to serial adapter or max232

[nockieboy]

No, I'm not using anything on the second port (B) - it's currently floating, I guess.

I intend to use it later on for expansion - most likely to connect a keyboard/display circuit.  Currently, however, it's not connected to anything...

[C]

Last I looked
on cold boot grant's software sends output from both.
looks for a space from one port
when space received uses that port for remaining time.

You do not care what port output is sent to
What you really want is that input comes from the port you want.
When this is true then Z80 sends output to this port

So during testing
initial output sent to both
output only sent to selected port after selection is made. This output tells you proper selection made. If output stops then Z80 likely selected other port.

Great code would send to unused port a message
" this is port B, Input is from port A".

If you force output to continue to both ports then you have no idea what port was selected for input unless the Z80 sends a message stating what port was selected for input.

Before sending any character from PC
RXDA & RXDB should be at same level.
While sending a scope should only see changes to one of these pins

If RXDA level not the same as RXDB  then strap  second port RXDB to same level to prevent noise creating a character.

I'm using the full monitor program as provided on Grant Searle's website and linked previously.

Just checking...

Anyway, if you get the scope out also check the INT line for activity when you send a char to the sbc.

Important test to do.

[C]

These days
  USB to serial TTL comes in versions for 5 volt logic and 3.3 volt logic.
Could be that you have a 3.3v one and the outputs are not making the SIO inputs happy.

Compare a high level output from the SIO to a high level output from the USB to serial TTL

With scope you could look at levels of SIO TXDA while Z80 sends message to PC.
Then look at USB to serial TTL Tx output while sending from PC and see if levels match.

Z80 SIO should swing about 5v
A 3.3v USB to serial TTL Tx pin would only be 3.3v or a little less.

An SIO input greater then 2v to see a high level and more is better up to 5v

 

[nockieboy]

Okay, I've made a few debugging changes to the monitor code.  To be clear on those changes:

* Only port A on the SIO/2 is connected to the USB/TTL lead
* Output from the SBC is only sent to port A
* Input to the SBC is only checked for against port A

The initial string is still displaying properly.

I have added debug strings to key parts of the code and have tracked down the execution to the following loop:

Code: [Select]

waitForCharA:
LD A,(serABufUsed)
CP $00
JR Z,waitForCharA

This is around line 220 in the monitor.asm file and is a loop within the conin: subroutine to get input from the SIO.  The SBC is locked in this loop on startup waiting for an input that never seems to come from port A.  For info, serABufUsed is defined in monitor.asm as:

Code: [Select]

serABufUsed .ds 1
I was interested to note that Grant seems to have set up an interrupt on port B, but not A.  I'm not really familiar enough with Z80 assembly or the SIO/2 to understand why he has done that and not with port A as well/either.  I've removed it from the assembly and added it for port A (in the hope a simple cut 'n' paste and change of SIOB_C to SIOA_C will do it!)

Here's how it was:

Code: [Select]

;LD A,$02
;OUT (SIOB_C),A
;LD A,$60 ; INTERRUPT VECTOR ADDRESS
;OUT (SIOB_C),A

I've removed that and added this:

Code: [Select]

LD A,$02
OUT (SIOA_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOA_C),A

Please let me know if that's wrong as well.  I'm reverting the interrupt vector back to SIOB_C as it is in Grant's original monitor.asm next to see if that makes any difference to my debug output (I'm sure it won't - it wasn't working before I made this change.)

[PA0PBZ]

It is very strange that it ends up in that loop because serABufUsed is already checked in waitForSpace and should never go to conin if serABufUsed is zero:

Code: [Select]

waitForSpace:
CALL ckincharA
;LD A,(serABufUsed)
;CP $0
;RET
jr Z,notInA
LD A,$00
LD (primaryIO),A
CALL conin
;PUSH HL
;LD A,(primaryIO)
;CP 0
;JR NZ,coninB
;coninA:
;waitForCharA:
;LD A,(serABufUsed)
;CP $00
;JR Z, waitForCharA


I also noticed the interrrupt set on port A only but I assumed that it was valid for both ports this way and did not go after the datasheet.