Not sure where to post this I hope "Hardware" is correct

First, I have read Garth's RS232 primer until I am red in the face so please don't ask me to go read it - I can nearly recite it off by heart

I am using both/either Rockwell 65C51 and WDS 65C61 - both do the same. I am using interrupt driven input (Garth's round robin buffers) but not interrupt driven interrupt driven output - instead I am using a simple delay loop on output while each byte is sent.

Here is my issue: If my input buffer fills and I turn on RTS with a $09 in the 6551s command register then my terminal program on the PC does indeed stop sending data until enough bytes in the input buffer are consumed and $01 is stored in the command register turning RTS off. All well and good EXCEPT, while RTS is asserted the 6551 will not transmit data. Is this correct? It doesn't seem right to me. The Rockwell datasheet
actually says that the transmitter is turned off while bits 2 and 3 are zero - although since no other datasheet says the same - here is WDC's datasheet. I have always assumed it is a typo in Rockwells sheet.
Surely, if the transmitter is disabled while RTS is asserted then the '51 can only ever be half duplex.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I gather(*) it is indeed the case that telling the sender to stop (using RTS) will also turn off the transmitter interrupts. This isn't quite what we'd want, but it's what we're offered.

I think we found on Acorn's BBC micro that the regular timer interrupt, as a sort of helpful side-effect, would check the outgoing buffer and send a character if there was one to send and if the ACIA was able to accept it.

Although that's unexpected and sub-optimal, it's not obvious from the overall behaviour of the machine - in other words, it works well enough.

As the ACIA has a one byte buffer for outgoing data, with a helpful combination of baud rate and timer interrupt rate there is perhaps not much - or any - decrease in the outgoing throughput.

Edit:
(*) I found out this year - it's sufficiently invisible that I'd not known it for some 30 years of using a Beeb.

Also, it's handy that the OS looks after serial input and output, managing small circular buffers, because it hides these low level details from the application. And, in the case of serial input, it's very desirable to ask the receiver to stop before there's no room left - there needs to be a high water mark, and a bit of spare capacity to allow for overrun. Acorn's MOS has an adjustable threshold for this, and in my case I've needed to use it, to avoid overrun. We've found that some modern USB to serial adapters overrun by as much as three bytes. Could be more, perhaps, depending on the driver and therefore on the OS at the other end.

Thanks Garth. So, you know your code, specifically the code in the ISR
Imagine I have received more than $F0 bytes and therefore have written #1 into the ACIA's command register to tell the other end to stop sending. Should I now be able to SEND bytes back to the PC? Because my tests show that I can't. All the time bits 2 and 3 in the command register are zeros my '51 will not transmit data back to the PC.

(I edited and added to my reply - just in case you missed it!)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You say ...will also turn off the transmitter interrupts. Do you mean Interrupts or just the transmitter? I find certainly the transmitter goes off but I don't know if the interrupt is turned off too.

Either way its really irritating. I was trying to get handshaking working with Tali Forth but if I stream test to Tali and the receiving routine says Too Fast and sets RTS to say stop, then everything stops because Tali is trying to echo the data stream back and it cant because the transmitter is now off so sits and waits to send the next char and doesn't consume anything from the input buffer so everythng stops. Shame. It looks like handshaking will be impossible. I can get round it by sending slower but that wasn't the point - I wanted to do it right - with handshaking. Oh well.

Do you have an output buffer?

I'm not crystal clear on what Acorn MOS does, but I know it works - and there's a well-annotated disassembly here:
https://tobylobster.github.io/mos/mos/S-s11.html#SP4

No, I don't.
Sorry, I'm having a hard time getting my head round the ramifications of an output buffer. It would have to be interrupt driven but having it would mean the input buffer may have time to drain and de-assert RTS... I'll have to think about it some more.

I assume in "Acorn MOS" you are talking about the BBC Micro but In the BBC Microcomputer service manual it shows a 6850 being used rather than a 6551 so I can't see the disassembly will help me (I don't know the 6850 at all). Still, its an interesting exercise to look through the code. Thanks for the link.

Setting up circular transmit and receive buffers is quite easy. I've been using such a BIOS setup for decades with the 6551/65C51 (albeit not with the latest WDC part). I use 128 bytes for transmit and another 128 bytes for receive. I also setup the 6551 and configure the terminal program for RTS/CTS handshaking, which has worked very well over the years. You might want to give it a try. You can try the BIOS section of my Micromon code (github page). The basic function is about the same as what is in the old 6502 Assembly Language Subroutines book from Leventhal/Saville, but I use CMOS instructions and such in my code.

_________________
Regards, KM
https://github.com/floobydust

Oh, sorry, I missed that the Beeb uses a different chip! (The oddity of RTS sounded familiar though, so perhaps they both do that the same way.)

Ed you are correct here - both the 6551 and 6850, it seems, share the same limitation that if you want to de-assert RTS (i.e. take it high) then as a side effect transmit interrupts are disabled.

You can still transmit characters, for example using timer interrupts to poll for "Transmit Data Register Empty", which is what the Acorn MOS 1.20 does.

This allows for full duplex operation, albeit with some loss of throughput at higher baud rates.

Dave

Maybe not all 6551 variants works the same - the datasheets certainly differ.

The MOS 6551 says "Transmit Interupt Disabled" rather than "Transmitter Disabled":
http://archive.6502.org/datasheets/mos_6551_acia.pdf

This post seems relevant:
viewtopic.php?p=14838#p14838

Adrian, which devices have you actually tried?

Dave

My take is the 6551 is meant to talk to a modem - not another serial device. For that the handshake is utterly unusable.

I'd recommend using separate IO for RTS/CTS or even switch to a 16550 UART. That even has a 16 byte send/receive buffer.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Hi Adrian,
Sorry for a slow response to your inquiry in the Tali Forth thread about this issue (I had a week-long family emergency), but it's probably better here as a new topic anyway. I use interrupt driven receive and polled transmit. It's important to have a non-WDC 65C51 (both you and I have Rockwell parts) to be able to use polled transmit. I regularly "paste" 20K or more at a time to my SBC over the serial port with no delays and save the results (using logging in my terminal) and I do not see the issue you have.

One thing I will mention is that your transmit routine, if it is polling the status register, also needs to check the RX bit to see if a byte came in while waiting to transmit. The act of reading the status register will clear the receive interrupt even though you are polling to transmit. To get it to work reliably, I ended up disabling interrupts in my transmit routine and handling any incoming bytes while I was polling to see if the tx buffer (single byte) was empty.

Are you using both the receive AND transmit routines from Tali's "platform-sbc.asm"? If not, can you post your initialization, transmit, and receive routines? I have the same Rockwell 65C51 you do, so I should be able to reproduce your setup.