Deluxe RS232 Pak
|Looking for CoCo help? If you are trying to do something with your old Color Computer, read this quick reference. Want to contribute to this wiki? Be sure to read this first. This CoCo wiki project was started on October 29, 2004. --OS-9 Al|
This page was last updated on 04/14/2020. Total Pages: 716. Total Files: 984.
RS-232 Pak Data Sheet
The heart of the Deluxe RS-232 Pak is the Synertek 6551 ACIA. It has an on-chip baud rate generator, programmable interrupts and status register for ease of operation, false start bit detection, and echo mode
This ACIA board is memory mapped to addresses $FF68 (65384) to $FF6B (65387).
The 6551 uses 4 memory addresses for the following functions:
|FF69||Soft Reset||Status Register|
This table shows that only the Command and Control registers are bidirectional. The Soft Reset operation clears the 6551 internal registers but does not cause any data transfer. Therefore, the data written is a "don't care." A RES* from the bus will clear all registers in the 6551 while a Soft Reset will disable interrupts and transmitter, turn off echo mode, and clear the Overrun Error flag only.
The following shows the Status, Command, and Control Register and gives programming examples for each:
Status Register ($FF69)
The Status Register is used to indicate to the processor the status of various SY6551 functions.
|STATUS||SET BY||CLEARED BY|
|Parity Error*||0=No Error
|Framing Error*||0=No Error
|Net Reusable Reflects DSR State|
|Net Reusable Reflects DSR State|
|Read Status Register|
*NO INTERRUPT GENERATED FOR THESE CONDITIONS.
**CLEARED AUTOMATICALLY AFTER A READ OF RDR AND THE NEXT ERROR FREE RECEIPT OF DATA.
Command Register ($FF6A)
The Command Register is used to control Specific Transmit/Receive functions.
|BIT||PARITY CHECK CONTROLS|
|-||-||0||Parity Disabled - No Parity Bit Generated - No Parity Bit Received|
|0||0||1||Odd Parity Receiver and Transmitter|
|0||1||1||Even Parity Receiver and Transmitter|
|1||0||1||Mark Parity Bit Transmitted, Parity Check Disabled|
|1||1||1||Space Parity Bit Transmitted, Parity Check Disabled|
|BIT 4||NORMAL ECHO MODE FOR RECEIVER|
|1||Echo (Bits 2 and 3 must be "0")|
|BIT||TRANSMIT INTERRUPT||RTS LEVEL||TRANSMITTER|
|BIT 1||RECEIVER INTERRUPT ENABLE|
|0||IRQ Interrupt Enabled from Bit 3 of Status Register|
|1||IRQ Interrupt Disabled|
|BIT 0||DATA TERMINAL READY|
|0||Disable Receiver and All Interrupts (DTR high)|
|1||Enable Receiver and All Interrupts (DTR low)|
Control Register ($FF6B)
The Control Register is used to select the desired mode for the SY6551. The word length, number of stop bits, and clock controls are all determined by the Control Register.
|BIT 7||STOP BITS|
|0||1 Stop Bit|
|1||2 Stop Bits|
1 Stop Bit if Word Length = 8 Bits and Parity*
1.5 Stop Bits if Word Length = 5 Bits and No Parity
- This allows for 9-bit transmission (8 data bits plus parity).
|BIT||DATA WORD LENGTH|
|BIT 4||RECEIVER CLOCK SOURCE|
|0||External Receiver Clock|
|1||Baud Rate Generator|
|BIT||BAUD RATE GENERATOR|
|0||0||0||0||16x ENTERNAL CLOCK*|
- This works out to be 115200 baud, and it *almost* works!
RS-232C Pin Description
|4||Request to Send|
|5||Clear to Send|
|6||Data Set Ready|
|20||Data Terminal Ready|
Increase Hi-Speed Performance
Notes about adding hardware handshaking and other modifications to the CoCo's RS-232 to increase hi-speed performance
Sock Master's notes about hardware handshaking and other modifications to the CoCo's 6551 based RS-232c Pak.
I've been running a BBS on my CoCo for the last 11 years or so. I'm usually a bit behind on the technology side compared to most other BBSes, but many people usually say that it makes the board more interesting. When I finally got myself a 14.4Kbps modem for the BBS a year ago, I decided to simply run my RS-232 at the maximum rate (19200 baud) and leave it locked there. No matter what baud someone called in at, the flow control lines of the RS-232 are supposed to keep my BBS from sending out too much data to low speed callers. Well, it turns out that that is technically correct, but the 6551 has a *lousy* way of dealing with CTS line changes. Every time the modem would raise the CTS, the 6551 would stop dead in it's tracks - right in the middle of sending a byte! For low speed callers, that meant every 200th byte or so was truncated and percieved as trash.
I couldn't think of a very elegant solution to that problem, but for the sake of my BBS, I solved it in the easiest way I could. I removed the CTS signal (pin 9 on the 6551 chip) from the 6551 altogether and rewired it to the cassette input (pin 4 on cassette port) with a 22K Ohm resistor. I then forced the 6551 to always think the modem is ready by grounding the CTS on the chip (Solder a wire from pin 9 to pin 1 on the 6551). I used the cassette port because it's a free input port that's generally unused by everyone. This works, but you have to patch your RS-232 driver to accomodate it. My new driver simply checks the state of the cassette port before deciding if it should wait to transmit the next byte or not. But, even with unaltered driver routines the 6551 will no longer destroy outgoing data and no problems will arise except in the case of the computer sending out more than 1.5K or 2K ahead of the modem, which is fairly unlikely. This is simple enough not to need a diagram, so I didn't include this in my drawing. The drawing is too crammed as it is already.
Now for what IS in the diagram: The other problem with putting a high-speed modem on my BBS is a little less important, but fixing it makes everything much easier. With this modification the CPU gets less bogged down, the RS-232 driver becomes easier to write, and the BBS *never* misses any incoming data. Normally, the 6551 simply has no way of telling my modem when it's data buffer is full. If someone called my BBS at a high baud rate and tried uploading a text file, my driver simply didn't read the data fast enough to get it all without missing bytes. Every time the disk drive went on, the CPU halts and the 6551 misses more data. In order not to miss data, the RS-232 driver would have to immediately read data from the 6551 every time a byte came in. The solution? I made a little circuit that sits on top of the 6551 chip (a 74ls32 and 74ls00) that generates a new RTS control signal. Since modern modems have a data buffer, it would be really neat to unload a lot of work from the CoCo and leave it for the modem to do. This hardware circuit simply creates a new RTS line for the 6551. Every time the 6551 receives data, the circuit raises the RTS line (which tells the modem to stop sending to the CoCo) until that data is read by the software. If the driver reads the data at the full incoming speed, there is no slowdown in throughput. If the driver goes on a break, or the disk drive comes into use... whatever, the modem is told not to send any more data to the 6551 until the 6551 is ready to recieve it! Effectively, the circuit disallows the 6551 from missing any data. It also places the job of buffering incoming data on the modem, and not the CoCo. The CoCo doesn't have to keep reading the 6551 every time a byte comes in, since it won't lose the data if it lets it wait. Now it can read the data when it actually wants it. This speeds up my BBS quite a bit, I only read from the 6551 when the BBS wants input from the user. If the user transmits stuff while the BBS is calculating, loading, thinking, etc... the modem will buffer it for me.
Note: I've recently been informed that the RTS modification has a side effect when used with certain kinds of modems. It works wonderfully with my U.S. Robotics 14.4 Sportster which has a 2K data buffer. But, it may function inefficiently with other modems lacking data buffers. What happens is that when the RTS coming from the the CoCo signals the modem that the 6551 is not ready to receive data, these modems may pass along this signal to the HOST computer and tell it to stop sending data until the CoCo is ready for more. (This happens because the modem does not buffer incoming data, therefore cannot store it if the CoCo is not ready to receive.) This extra step adds a delay between incoming characters because the signal ends up travelling huge distances across the phone line between each character.
I also rewired the line that goes to Carrier Detect (DCD pin 16 on 6551) signal to go to the DSR (pin 17) on the 6551. Make sure to cut any lines that previously went to the DSR pin on the 6551. Then, I wired the DCD (pin 16) on the 6551 to ground (pin 1). This way I can still recieve data when there is no carrier, but I can still be able to detect carrier status by checking the DSR state. (This is not shown in the diagram either because it's as easy as cutting two wires and rewiring two pins.)
Lastly, I did the silly thing of replacing the 1.842Mhz clock crystal on the 6551 with a 3.684Mhz one. This doubles all baud rates. The 6551 can now run at 38400 bps! (Warning: Many terminal programs that use GIME timer interrupts to drive the RS-232 will still sample the RS-232 at their old sampling rate (half the new rate required) which effectively reduces your throughput or causes lost data - So, this modification is not recommended unless you know that your software is driven by the 6551 Interrupt line.)
These four modifications each serve a purpose, but you don't need to attempt them all. Each particular modification will do it's job all by itself. You can try getting started with the easy modifications to the DCD or CTS first and then decide if you want to try the more serious hardware hacking of the RTS modification. If you want just a particular function of the 6551 'fixed', then you can do just that modification too. I have all four done to my RS-232, and they work wonders for the operation of my BBS.