Working around the W65C51 transmit buffer empty bug

[gfoot]

One thing to check perhaps is the exact timing. I have a feeling the receive interrupt fires halfway through the stop bit, which might be too soon to send the next byte.

[BigEd]

Welcome, John!

[John_M]

BigDumbDinosaur wrote:

Some notes:

Thank you for taking the time to look and offer such helpful feedback. I'll tie DCDB and DSRB permanently low. CTSB too, for the time being. It would be nice to be able to use CTS/RTS eventually but that's some way away. I've noted your points about IRQB, removing the diodes and reducing the value of R1.

gfoot wrote:

One thing to check perhaps is the exact timing. I have a feeling the receive interrupt fires halfway through the stop bit, which might be too soon to send the next byte.

Thanks, George. This ties in with BDD's final point about providing a delay in the link between pins 10 and 12 of U1. I only have the WDC datasheet to work from and it doesn't give that kind of information, so I'm going to measure it myself. I've been sketching out the software this morning but I realise Christmas is hurtling towards me so I'll have to take a break from it soon.

[John_M]

Thanks, Ed!

[gfoot]

This datasheet shows on page 16, figure 6, what continuous receive looks like, and states that the receive interrupt occurs 9/16 of the way through the last stop bit.

One way to delay this more or less in software would be to configure the dummy reciever to expect two stop bits rather than just one - then this interrupt will occur after about one-and-a-half stop bits, when it's already safe to write the next character to the other ACIA straight away without clobbering anything.

[John_M]

Thanks George. That's a much more comprehensive data sheet than the one currently available from WDC's site (dated August 21, 2021). I'll implement your suggestion, which means I'll have to revert to using the Rx part of U2 as the dummy and, no doubt, confuse myself in the process!

[gfoot]

I would still link RX and TX on one ACIA used for transmitting, with 8-N-2, and use the other one for receiving with 8-N-1 - also configuring the other end of the line to 8-N 1 as usual. I don't think it will work the other way around as the receiver would be expecting 8-N-2, so you'd need to configure the other end of the line as 8-N-2, and then you'd also need to transmit 8-N-2 but you're back to square one as you might be truncating those two stop bits a little. Overall you need the line to be principally configured as 8-N-1, though you'll send slightly longer stop phases in practice.

[John_M]

Quote:

I would still link RX and TX on one ACIA used for transmitting

Ah, right. I understand now. Thanks, George.

The attachments show where I am at the moment. None of this is tested yet and the code isn't complete so it isn't ready to assemble, but it should show where I'm aiming. I'm going to have to put it to one side for now because I'm under pressure to return to the real world for a while!

- John

[BigDumbDinosaur]

gfoot wrote:

One way to delay this more or less in software would be to configure the dummy reciever to expect two stop bits rather than just one - then this interrupt will occur after about one-and-a-half stop bits, when it's already safe to write the next character to the other ACIA straight away without clobbering anything.

That won’t work.  The transmitter and receiver would gradually drift apart in timing and things would fall apart.

[barnacle]

What am I missing, BDD? The transmitter isn't going to get new data to transmit until the receiver says it can, half way through the second 'stop' bit. So it should stay in sync since that will retrigger a new rx state with associated interrupt.

Neil

[John_M]

BigDumbDinosaur wrote:

The transmitter and receiver would gradually drift apart in timing and things would fall apart.

I'm not sure which transmitter/receiver pair you're referring to, but I assume you mean the Tx in U1 which is set to 8-N-2 and the Rx in the external PC that's set to 8-N-1? Doesn't that Rx simply see an 8-N-2 data stream as 8-N-1 with a short period of idle time at the end of each character, as George suggested, since stop bits have the same polarity as idle time? It is, after all, an asynchronous protocol.

[BigDumbDinosaur]

John_M wrote:

I'm not sure which transmitter/receiver pair you're referring to, but I assume you mean the Tx in U1 which is set to 8-N-2 and the Rx in the external PC that's set to 8-N-1? Doesn't that Rx simply see an 8-N-2 data stream as 8-N-1 with a short period of idle time at the end of each character, as George suggested, since stop bits have the same polarity as idle time? It is, after all, an asynchronous protocol.

Dunno what will happen.  In all the years I've worked with TIA-232, mismatched formats have always ended up with garbage at the receiver end.

[BigEd]

Yeah, seems fine to me... just think about what stop bits are and how they work.

[GARTHWILSON]

The original "solution," years ago when the bug was discovered, was to use a delay loop to make sure you don't give the ACIA the next byte to send before it's ready for it.  The receive interrupt solution, if its generating the interrupt only halfway into the stop bit time were truly a problem, could be fixed up with another delay loop, and this delay would be only about 5% as long as the original, so the processor still gets most of its time back to do other things.  (I'm sure others have thought of this too, but I didn't see anyone saying it yet.)

[barnacle]

It occurs to me that with a fast transmit speed, one might rely on the received interrupt half way through the first stop bit, and then entering a wait for tx empty. Worst case that's only going to be half a bit - say five microseconds at 115200 baud. And in that time is the inescapable interrupt response time anyway.

So you're going to be getting ~95% of the byte time available for other functions, which is a pretty low overhead.

(It also occurs to me that I've almost never relied on interrupts for tx anyway; rx, yes, usually to a buffer, but I tend to use a blocking transmit.)

Neil