Dr Jefyll wrote:
What does the scope say? Is the UART outputting a steady stream of properly formed characters at the expected baud rate?
Yup, scope looks decent (a bit of ringing, but that's an artifact of the breadboard, and doesn't show up nearly as much when I probe the tx line when it's connected to the serial dongle). It's still going too...been running the test for a couple of hours now and no errors detected. To make sure all eight bits are coming through I've also run the test with three additional values: $FF, $55, and $AA. All tests have passed and the scope looks good on all three.
So based on this test it looks like all the control and bus signals between the to/from the UART are functioning. At this point the only real difference between the test code and the real code is that the former is waiting for the byte to be received again before sending another, instead of just sending whenever TxRDY is set. It's interesting to note that TxRDY is bit $04, which is also the bit that should be set on MR0 to enable the extended baud rate II mode. At one point I thought maybe something was wrong with that particular data line, but the fact that all the loopback tests are working kills that idea.
I'm going to attach all the code that prints my banner just in case I missed something. Things to note:
- Everything of interest is still running out of bank $00, in the F800-FFFF "LOWROM" window.
- The CPU is in 8-bit native mode, because all of this code came from my previous, 65C02-based build.
First, here's my serial output code:
Code:
putc_serial1:
pha
lda #%00000100
@wait: bit nxp_base+nx_sra
beq @wait
pla
sta nxp_base+nx_fifoa
rts
At startup this subroutine is placed into the console_write vector, which is what everything calls to send text to the console (the idea being that at some point I'll have a real video output and can send there instead):
Code:
lda #$5c ; JML
sta console_read
sta console_write
lda #<getc_serial1
sta console_read+1
lda #>getc_serial1
sta console_read+2
lda #^getc_serial1
sta console_read+3
(The vector users JML but everything is still calling this via JSR from bank $00, and the function still returns with RTS.)
Finally, here's the string print function. It's the same as on the previous board, except it uses a 24-bit pointer.
Code:
writeln:
sta ptr
stx ptr+1
sty ptr+2
ldy #0
@loop: lda [ptr],Y
beq @exit
jsr console_write
cmp #CR
bne @notcr
lda #LF
jsr console_write
@notcr: iny
bne @loop
@exit: rts
There is a 100 Hz jiffy IRQ from the VIA that also toggles PB7 so I can verify that the board is still running even when the UART is bonkers. Just in case there was a problem with the IRQ handler code I've also tried wrapping writeln in a sei/cli pair; it didn't make a difference.