I am going to clean up the project. I will attach the project as soon as this has been done

In your foreground and interrupt code (ISR) for handling the transmitter I see you are wrapping the TxD queue at 128 bytes and have also defined TXQ at that size. I don't see wrapping occurring in the receiver's foreground and ISR. However, you are also defining RXQ as being 128 bytes.

Thank you ...

For those interested, I have attached the driver that is currently working for my board, for only one channel (as I need only on right now)
Please read the comment in NXP28L92.asm.

I use a cc65 build-environment and use the following commands:

$path_to/cc65 -l driver.lst -o driver.o NXP28L92.asm ...

I created a new debug.asm, in which I implemented the sprint functionality, but pointing to the DUART routine(s). Up to 256 bytes are sent correctly, but when I want to send > 256 bytes, the routine doesn't seem to return...

I think I found the issue. Has nothing to do with the ISR or frontend ...

I created a new debug.asm, in which I implemented the sprint functionality, but pointing to the DUART routine(s). Up to 256 bytes are sent correctly, but when I want to send > 256 bytes, the routine doesn't seem to return...



.org $3000
.p816

; macros
.macro longi ; Set .X and .Y to 16-bit ...

Oh, I think i May have found the issue with (longer) strings! Going to try to rewrite your (BDD) sprint routine for the DUART

For legibility purposes, I removed the commented-out code and extra whitespace between mnemonics and operands, and reduced text size. BTW, all datums in TxQ are "new." :D
I will change this comment ;)


I'm not seeing anything here that would cause a loop on handle_thr_a . You said it's "looping ...

Did a few extra testing and found that when I:

try to send <= 256 bytes, it works as expected
try to send > 256 bytes, the "@handle_thr_a" keeps looping somewhere...

This tells me that I have some bit in the SR set, but should be cleared? Which affects one or two branch conditions?



0040E7 ...

Hmm, "index" wrapping" seems to work. When I try to send a string several times, I can see the index wraps. But when I try to send >128 bytes, it looks like a (new) interrupt interrupts the interrupt?
(Did I mention I use 19k2 8N1 for serial?)

Next step is looking at "easier/nicer" way to drive ...

Thank you for the feedback!

at 403a: error -----------------------------------------------
403a & 403f don't wrap the same way as at 40f1 - it'll go to values that the interrupt handler can never get to.
The interrupt handler will keep retransmitting old bytes trying to get there.

at 4012: error ...

It looks like it has something to with the THR IRQ handler for channel A. But somehow I cannot seem to find it.

What happens:
When sending data, e.g. > 127 bytes of ASCII, the interrupt handler seems to "break" and hangs the computer. I have to /RESET to regain control. First I thought it had ...

I just resized the code block (and will try to remember to do so in the future!)

Thank you for the input, I will remove the shortr macro at that location (and save a few cycles).

It seems that when sending data, the send buffer will not wrap. First, when I had half page buffers, receiving seemed ...

Got some more success with the driver (some reading here, some "stealing" there... crashes, having to rewrite IRQ handler in ROM to support separate emulation and native 65c816)

Currently I am stumbling upon an issue when sending large data sets.



000000r 1 ...

Maybe I have found the culprit...

"Adria" might have to enable the counter by reading IOBASE + dr_cnt_start (Start counter command)?!

I now have a 100Hz /IRQ signal and the counters are incrementing/decrementing...

I did just test if the 28L92 is actually "working" by storing a byte in register $0C (Misc register) and reloading from that register. This seems to work correctly