In fact, a temporary loopback could be used to see if what comes out of the receiver agrees with what goes into the transmitter, all the while watching activity on the 'scope. All it would require would be to wire pins 33 (TxD) and 35 (RxD) together, with that junction the pickoff point for the 'scope. Hardware handshaking should be disabled for this test.

The test code would execute as follows:

1. Poll TxRDY until it is set.
   
   
2. Write datum to transmitter FIFO.
   
   
3. Poll RxRDY until it is set.
   
   
4. Read datum from receiver FIFO and compare to what was written to the transmitter.
   
   
5. If the comparison in step 4 fails, halt and indicate an error in some fashion.
   
   
6. If the comparison in step 4 succeeds, return to step 1 and repeat.

Failure would the result of improper setup (bit rate and/or data format), a faulty UART, faulty X1 clock, or glue logic errors. You could try this testing on the second channel if failure does occur.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I've had this running for about 30 minutes so far and it's not reporting any errors. Here's the code I'm using:



I was really hoping this test would fail...

What does the scope say? Is the UART outputting a steady stream of properly formed characters at the expected baud rate?

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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:



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):



(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.



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.

That it didn't fail eliminates the DUART as the prime suspect. You need to take another look at your serial interface. If it were me, I'd be rigging up a serial transceiver (1488/1489 or MAX23*) and directly driving the serial port of a PC, dumb terminal or similar. If you were to do this and get a coherent display then you will have the direction needed to solve this problem.

Also, since your computer is connected with a big mess 'o wires, pay attention to lead dress and the quality of the connections. You may have one flaky connection that is giving you grief.

Incidentally, a slightly more efficient way to poll the receiver is as follows:

Code:

         lda #%00000001        ;RxRDY flag bit  <—— should be symbolically defined, not hard-coded
;
@rxdrdy  bit nxp_base+nx_sra   ;RxD have a datum?
         beq @rxdrdy           ;nope
;
         lda nxp_base+nx_fifoa ;read datum

          ...etc...

A similar technique for processing the transmitter could also be used.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

As I mentioned in another post I really haven't got anything that does native serial lying around anymore. I do think I have a true RS-232 serial dongle that I used to use to talk to switches & routers when I was a sysadmin, and I have over a dozen MAX232s in my parts box, so I can at least rig something up with that and see what happens. I'd love to have a dumb terminal but I'm already pretty cramped for space.

The bad serial dongle theory, however, still doesn't explain why I cannot get the BRG to flip to extended mode II. As far as I can tell that is the only thing in the setup table that's not working, and it's consistently not working (eg i have yet to have the board randomly boot up and be in the proper mode, and I can reliably set any bit rate I want as long as it's from the normal mode table). I can't even get extended mode I to work; it still ignores that piece of the initialization sequence.

Good progress to report. The replacement crystals and UARTs arrived yesterday, and after swapping out the crystal I got an immediate improvement. I'm now getting a pretty solid 38.4k with no missing characters! I have no idea what was wrong with my ebay crystals; on the scope the waveform looks the same as what i'm getting from my ECS-branded crystal, but obviously they weren't up to snuff for this. I think I only paid a buck each for them, so no big loss.

Unfortunately I'm only getting 1200 bps when i request 115.2k, and I've even swapped out to a brand new NXP-branded version of the UART, so obviously there is something wrong with my driver that I need to find. I'm going to keep poking at that as I feel like it, but as long as I'm getting 38.4k for now then I'm happy. If this is the only remaining problem I end up having I will declare this prototype build a success and move on to designing the actual PCB and building a final version.

Thanks everyone for your help. You guys were awesome as always!

I don’t know if this is relevant to your problems, but crystals are available in series or parallel resonant types. If the wrong type of crystal is used, it can oscillate at a slightly different frequency to that marked on it. Alas, that is the limit of my knowledge on this. It would be good if someone who knows more can jump in with more details. NB “crystals series parallel resonant” gets plenty of hits in a search engine.

And of course, it is always buyer beware with trading sites like eBay. Maybe the crystals that were sold to you were cheap because they did not meet the specifications that a normal component supplier would require.

Mark

Crystals?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sorry, oscillators. I sometimes mess up the two terms.

Was wondering.

I suspect you got some oscillators whose outputs either weren't swinging rail-to-rail or were grossly asymmetric—or both. I know from my piddling around with the NXP UARTs that an oscillator with TTL output instead of CMOS will not drive the UART hard enough to make it "happy."

Now that you've got the circuit apparently working you can now refine your driver to run both channels using IRQs and take advantage of the FIFOs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!