6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Nov 13, 2024 6:32 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: 6551 handshaking
PostPosted: Thu Dec 15, 2022 11:07 pm 
Offline

Joined: Sat Apr 30, 2022 7:13 pm
Posts: 159
Location: Devon. UK
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
Attachment:
rock51.JPG
rock51.JPG [ 18.88 KiB | Viewed 1558 times ]

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.
Attachment:
wdc51.JPG
wdc51.JPG [ 30.4 KiB | Viewed 1558 times ]

Surely, if the transmitter is disabled while RTS is asserted then the '51 can only ever be half duplex.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 12:01 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
___
RTS (Request To Send, not) is negative logic; so "high" is not the asserted state.  It has to be low (at the ACIA), which is the 'true' state, to transmit.  It should not be sending anyway without telling the receiving end that it is intending to send (by putting this line low) and without the receiving end telling the transmitter it's cleared to send.

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 8:30 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 8:37 am 
Offline

Joined: Sat Apr 30, 2022 7:13 pm
Posts: 159
Location: Devon. UK
Thanks Garth. So, you know your code, specifically the code in the ISR
Code:
         JSR  BUF_DIF     ; Now see how full the buffer is.
         CMP  #$F0        ; If it has less than 240 bytes unread,
         BCC  end         ; just exit the ISR here.

         LDA  #1          ; Else, tell the other end to stop sending data before
         STA  ACIA_COMM   ; the buffer overflows, by storing 1 in the ACIA's
                          ; command register.  (See text.)
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 8:45 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
(I edited and added to my reply - just in case you missed it!)


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 10:25 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
Ah yes, I haven't thought about the details much in many years, as what I have has been working for my applications for so long, so I haven't had to deal with the innards.  It is alluded to in the article [1], in the paragraph that contains, "Well, like so much of today's RS-232 implementations, that specification broke down."  I've also mentioned here that I'm not crazy about how the '51 has merged a couple of controls there to avoid having to add another register and register-select pin.  If there really does exist the possibility of having to throttle incoming data while transmitting at the same time [2], you might have to use a VIA bit for the RTS.  CA2 or CB2 (which are controlled in the PCR) might be a good candidate if you need to keep the 8 bits of each port together.  When not using an ACIA, I've used its DTR\ and RTS\ outputs as general output bits for other things; but although you're probably not using DSR\, DTR\, and DCD\, I see now in the Rockwell book that setting the DTR\ false disables the transmitter too, meaning you couldn't use that as an RTS\ replacement.  The Synertek book is not clear; so I don't know if that's just an omission, or if the design is actually different.


[1] That's one of the first articles I ever wrote.  Nothing is off-limits to improve though; and if we figure out something here, I'll edit the article.
[2] (which I suspect is kind of rare, because if you're behind on handling the input, you probably don't have time to be sending either, unless it's simply a higher priority)

_________________
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 4:48 pm 
Offline

Joined: Sat Apr 30, 2022 7:13 pm
Posts: 159
Location: Devon. UK
BigEd wrote:
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..
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 6:14 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Fri Dec 16, 2022 11:02 pm 
Offline

Joined: Sat Apr 30, 2022 7:13 pm
Posts: 159
Location: Devon. UK
BigEd wrote:
Do you have an output buffer?
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Sat Dec 17, 2022 12:30 am 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Sat Dec 17, 2022 9:09 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.)


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Sat Dec 17, 2022 10:36 pm 
Offline

Joined: Sun Jun 29, 2014 5:42 am
Posts: 352
BigEd wrote:
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Sat Dec 17, 2022 11:13 pm 
Offline

Joined: Sun Jun 29, 2014 5:42 am
Posts: 352
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Sun Dec 18, 2022 8:51 am 
Offline

Joined: Tue Jul 05, 2005 7:08 pm
Posts: 1042
Location: near Heidelberg, Germany
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/


Top
 Profile  
Reply with quote  
 Post subject: Re: 6551 handshaking
PostPosted: Wed Dec 21, 2022 2:19 am 
Offline

Joined: Sun May 13, 2018 5:49 pm
Posts: 255
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: