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:
Ah, that's because I removed the code that checks for a zero in A as I wanted it to default to the A buffer... looks like that edit wasn't such a good one.
Here's what I had:
waitForSpace:
;CALL ckincharA
;jr Z,notInA
;LD A,$00
;LD (primaryIO),A
CALL coninA ; DEBUG - only checking A for input
CP ' '
JP NZ, waitForSpace
JR spacePressed
After your comment, I've changed it to:
waitForSpace:
CALL ckincharA
JR Z,notInA
LD A,$00
LD (primaryIO),A
CALL coninA
CP ' '
JP NZ, waitForSpace
JR spacePressed
EDIT:
Looks like it's still stuck in a loop waiting for a character to appear in SerABuff or SerBBuff.
You asked previously to connect TXA and RXA together on the USB/TTL lead. Doing that whilst connected to the SBC doesn't echo any characters, but if I don't connect the USB/TTL lead to the SBC and connect TXA/RXA together with no flow control on the terminal, I get echoed characters. Is there something stopping the SBC from receiving data?
I asked you (or was trying to ask) to connect the TX and RX on the cable and leave the connection to the RX of the sbc intact but disconnect the TX of the sbc.
Does it echo?
CABLE TX---------SBC RX
|
CABLE RX---x SBC TX
I asked you (or was trying to ask) to connect the TX and RX on the cable and leave the connection to the RX of the sbc intact but disconnect the TX of the sbc.
Does it echo?
CABLE TX---------SBC RX
|
CABLE RX---x SBC TX
It does echo, but only after a cold reset of the SBC.
I asked you (or was trying to ask) to connect the TX and RX on the cable and leave the connection to the RX of the sbc intact but disconnect the TX of the sbc.
Does it echo?
CABLE TX---------SBC RX
|
CABLE RX---x SBC TX
It does echo, but only after a cold reset of the SBC.
So when you have it powered up and connected normally, and then move the wire from SBX TX to CABLE TX it does not echo?
So when you have it powered up and connected normally, and then move the wire from SBX TX to CABLE TX it does not echo?
Okay, I powered up the SBC with the USB/TTL lead connected normally. After the normal initial cold-reset, the 'Press space to continue' string is displayed. I then disconnected the SBC TX from the cable and connected the cable TX and RX together and characters are being echoed.
Ok, so the sbc is not shorting the received data, that is all I wanted to know.
Since I don't think it is a software issue I suspect your hardware, either a problem with the SIO or the interrupt handling.
You probably need to get the scope out to find out if it is the INT.
Is this still on a breadboard? Can you post a high-res picture of the complete board?
Ok, so the sbc is not shorting the received data, that is all I wanted to know.
Since I don't think it is a software issue I suspect your hardware, either a problem with the SIO or the interrupt handling.
You probably need to get the scope out to find out if it is the INT.
Is this still on a breadboard? Can you post a high-res picture of the complete board?
I'll be able to get some time on the 'scope this weekend, but until then here's some pictures as requested. Not sure they'll help much as the SBC is still on breadboard and is a bit of a rat's nest of wires... The SIO/2 is the chip in the middle of the SBC.
First picture is taken without the USB/TTL cable connected. SIO/2 is the chip in the middle.
The second is a close-up of the SIO/2's control connections.
Third image shows a closeup of the USB/TTL connection.
Fourth image - SBC powered up, from different angle.
Last image shows a closeup of the Z80.
Still reading to catch up
On thing I saw was
Interrupt vector for SIO only being for channel B
There is only one Regester to store the vector address for the whole chip and it is set and read via The be regesters
Think grant uses a vector of 60
So the code and the vector must match
WRDY is an output so it can be left alone. SYNC seems to be an input but if this is TTL technology an open input will be high. Use a pull-up if it makes you feel safer, pull-down seems the wrong thing to do.
From the linked document: "SYNC not used, pulled high by 10k resistor"
WRDY is an output so it can be left alone. SYNC seems to be an input but if this is TTL technology an open input will be high. Use a pull-up if it makes you feel safer, pull-down seems the wrong thing to do.
From the linked document: "SYNC not used, pulled high by 10k resistor"
My apologies, I meant high.
Why is your 74138 missing the address line inputs?
Still reading to catch up
On thing I saw was
Interrupt vector for SIO only being for channel B
There is only one Regester to store the vector address for the whole chip and it is set and read via The be regesters
Think grant uses a vector of 60
So the code and the vector must match
I wondered about this myself, C. I don't know enough about the SIO or interrupts in general to know what's going on there. It seems to me from Grant's code that he's just setting up the interrupt on port B. In his design, he's primarily using port B to interface to a computer. I'm wondering if he's mentioned the use of a TTL connection on port A, but forgotten to create the necessary interrupt for it in case it is the primary means of communication with a host?
So, should I remove the interrupt on B (as I'm not using it - but may later down the line to implement an I2C interface, but let's not get ahead of myself!) and copy/paste the interrupt code to set up the interrupt on A? Would the code be the same, except for referencing SIOA_C instead of SIOB_C? i.e.:
LD A,$02
OUT (SIOA_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOA_C),A
Would that work, or does the command ($02) need to be changed too?
I've checked the monitor code - $60 is a valid address for an interrupt:
;------------------------------------------------------------------------------
; SIO Vector = 0x60
;------------------------------------------------------------------------------
.ORG $0060
.DW serialInt
Thing is, I've inserted a debug print into the interrupt code and it's never called;
;------------------------------------------------------------------------------
; Serial interrupt handlers
; Same interrupt called if either of the inputs receives a character
; so need to check the status of each SIO input.
;------------------------------------------------------------------------------
serialInt:
PUSH AF
PUSH HL
PUSH AF ; DEBUG
LD A,'X' ; DEBUG
RST 08H ; DEBUG
POP AF ; DEBUG
; Check if there is a char in channel A
; If not, there is a char in channel B
SUB A
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,
JR NC, serialIntB
As you can see, I should be seeing the letter 'X' every time the interrupt routine is called, but I'm getting nothing like that from the SBC. It's getting as far as checking serABuff and getting stuck in the loop I mentioned previously.
Why is your 74138 missing the address line inputs?
They're the blue wires connected to pins 1-6 on the 74138?
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:
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:
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:
;LD A,$02
;OUT (SIOB_C),A
;LD A,$60 ; INTERRUPT VECTOR ADDRESS
;OUT (SIOB_C),A
I've removed that and added this:
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.)
Way back in this post you state changing from writing the chips vector address from
channel B register 2 with a value of 60
To
channel
A register 2 with a value of 60
This is a Problem
The Vector register only exists in channel B bank of registers
ONLY ONE VECTOR FOR WHOLE CHIP
put is back
Why is your 74138 missing the address line inputs?
They're the blue wires connected to pins 1-6 on the 74138?
My bad, got fooled because it's upside down in the picture
Way back in this post you state changing from writing the chips vector address from
channel B register 2 with a value of 60
To
channel A register 2 with a value of 60
This is a Problem
The Vector register only exists in channel B bank of registers
ONLY ONE VECTOR FOR WHOLE CHIP
put is back
Yes, I returned this to normal a while back, so the interrupt is being set up for B as per the original code.
My bad, got fooled because it's upside down in the picture
Darn - was hoping there was an easy solution I'd missed.
Fine print or what is happing
The contents of of B channel Regester #2 is used as the lower part of the Interrupt vector address
Register #2 only exists for channel B
So right now I have know idea where an interrupt is jumping to
LD A,$02
OUT (SIOB_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOB_C),A
is what makes
;------------------------------------------------------------------------------
; SIO Vector = 0x60
;------------------------------------------------------------------------------
.ORG $0060
.DW serialInt
work properly
Think PA0PBZ
has been checking normal connections for SIOA
If you have checked all to the Port to PC then the only thing I can think of that effects receive and not TX is receive clock
Check that pin 13 is connected to pin 14 of SIO
This goes other places but should be the Clock for all channels
Think PA0PBZ
has been checking normal connections for SIOA
If you have checked all to the Port to PC then the only thing I can think of that effects receive and not TX is receive clock
Check that pin 13 is connected to pin 14 of SIO
This goes other places but should be the Clock for all channels
Pins 13 (RxCA) and 14 (TxCA) are both connected to each other AND to pin 20, CLK. I have checked the clock signal to 13 & 14 previously and it is fine.
Grant seems to think the interrupt is triggered by both ports (A & B) according to a comment in the monitor code. I can confirm that the interrupt is set up on my SBC as per Grant's code:
LD A,$02
OUT (SIOB_C),A
LD A,$60 ; INTERRUPT VECTOR ADDRESS
OUT (SIOB_C),A
Pulling SYNC/A high doesn't make any difference - same problem as before.
I think my next step (until I can get the oscilloscope out) is to connect up port B to the USB/TTL cable and see if that makes any difference. The code is checking for I/O on both ports, so it shouldn't matter.
Do you have port B on a header so it's easy to connect?
Have you tried connecting the currently un+used RXDB to a level so that no noise can get in?
Do you have port B on a header so it's easy to connect?
Have you tried connecting the currently un+used RXDB to a level so that no noise can get in?
Not yet, but I'm make it so I can just plug the USB/TTL cable into another part of the board to get to port B.
Yes, I have tried pulling RxDB high and low - neither makes any difference.