scotws wrote:
Dr Jefyll wrote:
But isn't it more likely the ACIAs on the '256 have the same problem? I hope I'm mistaken. But AFAIK they're made with the same technology.
Aiee, I hadn't thought of that. So much for that idea. Back to the normal 65816.
The whole UART situation is increasingly irksome. Maybe I should just use the 65SPI to commect to something like the MAX3420E for USB access to the computer acting as a terminal ...
There are a gazillion UARTs available from a variety of sources, so there is no reason to fret about the (partially brain-dead) 65C51. I'm partial to Philips/NXP UARTs due to their performance, flexibility, availability of one or more microsecond-precision timers, and apparent freedom from hardware errata. POC V1.1 uses the 26C92 dual channel UART (DUART) and runs both channels at 115.2 Kbps with ease.
Aside from the DUART, NXP also produces QUARTs (four channels) and OCTARTs (eight channels), all of which are very similar in terms of programming. Adaptation of any of these devices to the 65xx bus is possible with simple glue logic. The maximum "standard" data rate with NXP UARTs is 230.4Kbps, with 960Kbps the maximum using a non-standard baud rate generator setup. Just about all of them also support TIA-485, which being balanced to ground, can be operated at high data rates over considerable distances (up to 1200 meters or ~4000 feet).
POC V1.1 uses a single MAX238 transceiver in an SOIC24 package to interface the 26C92 to the two serial ports. POC V2 will use the NXP 28C94 QUART to implement four serial ports, and will use a single MAX248 transceiver to interface to them. Some time in the future, I will probably build a POC Vx with eight serial ports, using the NXP 28L198 OCTART, with two MAX248 tranceivers. Thanks to the fact that all of these UARTs have a similar structure and register layout, I was able to develop a "universal" driver that works with any of them.
A feature of these UARTs (and the 16C5x0 series used with PC hardware) is the availability of receive (RxD) and transmit (TxD) FIFOs, the use of which can substantially improve real-time serial I/O performance. When I rewrote the driver in POC V1.1 to use the 26C92's TxD FIFO I noted a significant reduction in the number of IRQs being generated during output to the console, especially when large areas of the screen are being painted. This is because the interrupt service routine (ISR) polls the channel after each write to see if the TxD FIFO still has room. If it does, the ISR loops back and stuffs another byte into the FIFO. Only when the FIFO is full, or no more data is available to be transmitted, does the ISR terminate the loop. The result is that up to eight bytes can be transmitted per IRQ, versus one byte per IRQ with the 65C51.
Similarly, the 26C92 doesn't immediately interrupt when data arrives, as there is also an RxD FIFO. Instead, the 26C92 waits until the FIFO is full before interrupting. The ISR then repeatedly reads the FIFO and stores bytes until the FIFO is empty, which means up to eight bytes can be received per IRQ. In the event fewer than eight bytes are stored in the FIFO and no more data is immediately forthcoming, a "watchdog" timer will eventually generate an interrupt to tell the MPU to get what data is available, thus assuring that stale data isn't left in the FIFO.
I also have a 26L92, which is a 26C92 with 16 deep FIFOs instead of eight-deep, which I will eventually try out on POC V1.1. According to the NXP data sheet, the 26L92 is pin-compatible with the 26C92 and at reset, looks like a 26C92 to the rest of the system. A bit has to be flipped in a register to enable the 16 byte FIFOs. Otherwise, the programming model is the same and (in theory) should work with my existing driver.
Use of 65SPI to attach a UART adds a layer of hardware and software that may limit performance and flexibility. Doing so would be, in effect, "double serializing" the data flow, with attendant performance hits. When I designed POC I briefly flirted with using 65SPI but wanted to have dual TIA-232 channels. Doing it through 65SPI would have significantly complicated the unit, especially the software. The DUART proved to be much more efficient, plus fewer parts were needed on the PCB, which helped with the layout.
As for using USB, the software required to implement it can be complicated, especially on the 65xx side of the interface. TIA-232 is almost trivial in comparison. If your PC doesn't have a serial port one can be readily added with an inexpensive PCI card, such as
this Startech serial adapter. Another thing to consider is that USB is a very short-range interface, with an outer limit of five meters (~15 feet). A properly wired TIA-232 hookup can be operated over a span as great as 150 feet using inexpensive CAT5 UTP cable. It's not likely that most of us will be trying to run our 65xx contraptions from across the street, but it's nice to know that a longish cable is not likely to introduce the strange data corruption problems that will occur if a USB lash-up is too long.
Login
Register
FAQ
Search
-- that might be another another potential drawback. It seems pretty disorganized, and -- at 60 pages -- rather brief. I'd worry about how many important comments and details are missing. The chip has a 
This seems to imply the '256 could be used simply for its resources as a super-IO chip. IOW, use an external CPU, which exploits all the timers, UARTs, etc, etc. Or use both cpus.
. Thanks for the background, I actually have the 2692 here. I'll probably see about rebuilding my "Mark Zero" breadboarded 65C02 with it to gain some experience first, and then decide. Hadn't heard about the XR68C92 until now, but then I have been ignoring the PLCC chips.