So, you are all right and embarrassingly so! I royally screwed up the power on the VIA and ACIA.
The library for those parts have the power pins as a secondary, optional, part. This usually isn't a problem, as the VCC and GND connections should still happen automatically. It just so happens that these parts use VDD and VSS instead. So, they are wired to each other for power and nothing else.
On a second look, the CPU was wired the same way. Three chips powered completely wrong. I amazed it did anything at all!
The serial output is perfect now. Nothing gets hot. I think the case is closed.
Thank you to everyone for your input. I never would have guessed the power connections were suspect.

It's always nice to hear it's solved.

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

Skidlz:

Glad you found your problem. Things like that happen. Over the past 20+ years of owning my own business, it's has happened to me a number of times; luckily the number of times it's happened has been less than number of fingers on one hand (thumb not included). It's always embarrassing, but generally easily rectified.

I recall one particular instance, where we designed a custom interface for an important project using a socketed PLCC-84 FPGA. The design required at least 6 layers to route. After powering up the FPGA and checking power, we noticed that after we ran the FPGA through any significant amount of processing, the FPGA would quit talking with the on-board control processor, a venerable Intel 80C31 microcontroller. We would reboot every thing, and all would be good until we sent another long data stream to the FPGA. Short bursts of data were all processed fine. The FIFOs all checked out; there were no overflow or underflow conditions, etc. The power supplies were all low noise. One thing we did notice was that decoupling caps for the FPGA, mounted in the center area under the FPGA on the back of the board were just not at the same voltage level as the decoupling caps on the rest of the board.

After many frustrating hours trying to add caps here and there, all the time suspecting internal "ground bounce" in the FPGA, we had the inspiration to look at the Gerbers for the power planes. Imagine our surprise and embarrassment when we discovered that the power plane on the central part of that PLCC-84 socket was unconnected from the power plane on the rest of the board because the design rules, which we had not adjusted, were set with too large an internal power plane back off for the hole pattern of the FPGA socket.

The FPGA socket placed the power pins of the FPGA on the inner part, and thus they were actually floating. The FPGA was being powered parasitically from its I/O pins. The decoupling capacitors tied to that central, unconnected power plane, would hold up the FPGA under light loads, but the internal load and external I/O loading would cause them to droop too much that the FPGA would finally quit working.

To avoid this issue, we now religiously adjust the manufacturing design rules for power plane backoff as soon as possible. Another procedural change that I've adopted is to not rely on the power net names in schematic symbols from either my library or third party libraries. I now place visible power pins on all my schematic symbols. It actually makes the symbols more portable across the various power domains my HW designs support, and has helped me avoid shorting or leaving disconnected power and ground on big or little parts.

_________________
Michael A.

After gerberizing my PCB layouts, I check the result on the gerber viewer to make sure no unwanted effects like that sneak in. The power and ground planes are the most likely to need fixing. I use gerbv which is a free gerber viewer for Linux and it downloaded and installed in a jiffy from the Ubuntu software center. Edit, 12/1/16: I see there's a free 3D online gerber viewer at http://mayhewlabs.com/3dpcb .

I make all my own PCB components in the CAD, primarily to get greater density. I don't use the supplied libraries. Much greater density can also be achieved by a good human router than by an autorouter too, so I don't use autorouters. I have not seen any schematic capture that I like (although I got very proficient with OrCAD at my last place of work), so I've been doing my schematics by hand.

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

Legend has it that a similar thing happened at Acorn when the first ARM chips came back: