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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It is interesting to note that completely unaware of W65C51 limitation, I’ve designed a CPLD to emulate 6850 ACIA which is very similar to 6551. While the design fitted the small CPLD, I wanted to use the CPLD as the glue logic for processor, so I was forced to pare back functionalities including removing the serial transmitter shift register and associated control/status logic, and replaced it with a bit-bang transmit. The resulting serial port operated very similar to W65C51 with double-buffered serial receiver in hardware and bitbang transmitter controlled with software wait loop. It is fixed at 115200N81 and worked with 30Mhz 6502 without wait state. The logic also fitted inside a 64-macrocell CPLD with plenty room for other functions. It became my standard serial port library module. So, yes, W65C51 is a lousy UART, but the software workaround for it can resulted in simplified hardware that has application in smaller programmable logic. I continue to read the discussions about W65C51 with interests.
Bill

That sounds great Bill, is there a place to look at your source?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Tsk, the youth of today... when I were a lad we didn't even have UARTs, we had to wave flags from hilltops, that we had to climb in the snow, uphill both ways...

Neil

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I talked about the design of CPLD including the serial port in this rather long thread, viewtopic.php?f=6&t=6440 . Homepage is here and it has a PDF schematic of the CPLD design. It has been several years since I looked at the schematic, so I see I've a very simple version of the serial port buried in the middle of the schematic. The CPU clock is multiple of 1.8432MHz, so bit rate generator is just divided-by-N of CPU clock. No hardware serializer because it is done in software via bit-banging. Second page of the schematic shows the details of hardware receiver. The serial port is a small part of the CPLD which has RAM decode, 64-byte ROM, I2C, compact flash interface, all fitted inside an EPM7064S which is equivalent to ATF1504. The simplicity of the design allows the hardware to run fast; this design has been overclocked to over 30MHz.
The Z80 equivalent of the serial port is more complete because the targeted software auto-detect serial device, so I need to have correct emulation of software reset, interrupt generation, hardware handshakes in order to "fool" the software. Good thing about programmable logic is the device's features can be tailored to a particular application, thus reducing required logic.

A systematic approach to smoke signalling is integrate it into guard towers built on top of hills and connect the guard towers via tall walls, top of wall is flat to support rapid deployment of troops. It had been around for couple thousands of years.
Bill

(Thanks for the pointers!)

Yes, having "grown up" with the 6850, I'm so used to things like CTS propagating into TxRDY, so you don't have to test for CTS yourself, you just have to test for TxRDY. I can see how people get spoiled with UARTs that have their own baud generator though.

I'm only researching 6551 coding to add it to the options available for some of my code after discovering it via the BenEater system. From this and discussion here I've so far written up 6551poll.asm and made a start on IRQ-driver sample code.

(I've discovered somebody using a 6532 for serial I/O, so I've pencilled in looking at that later.)

With the BenEater also having a 6522 it's possible to use that to finagle a TxRDY signal. My first thought was programming it to provide a centisecond counter (which is usually a basic feature of my systems) and using that to trigger a countdown. Then a quick bit of scribbling showed that each tick would be 10,000 cycles apart when only 520 cycles is needed for 19200 at 1MHz!

Edit:
It slipped my mind while typing, but the other (more major?) issue is that with TxEmpty always forced ON there's no way of testing if the other end is saying "WOAH!", so the work-around of monitoring CTS directly by connecting it to another pin that is testable.

_________________
--
JGH - http://mdfs.net