On Sat, Mar 17, 2012 at 10:17 PM, Mouse <mouse at rodents-montreal.org> wrote:
"Posh" is a great way to put it! ?The 8530 is a fantastic chip.
Isn't that the chip Sun used on most of their SPARCstations?
Yes, and on most/all 68K Macs.
If so, I
disagree in at least a few respects. ?I *think* it has basically no
FIFO...
It has no FIFO. It came from an era before serial chips routinely had
FIFOs, but I've used it at 56K and faster with no problems - your CPU
just has to keep up, which I know was a problem in the DOS era with
8250 and 16450 serial chips.
?Also, to quote NetBSD's z8530reg.h (version 1.12,
in case
anyone cares),
?* The damnable chip was designed to fit on Z80 I/O ports, and thus
?* has everything multiplexed out the wazoo.
That is true. It _is_ possible to stick it on a 68000 bus, but some
glue logic, including, possibly wait-states or careful driver crafting
may be required.
...?We have to select
?* a register, then read or write the register, and so on. ?Worse,
?* the parameter bits are scattered all over the register space.
?* This thing is full of `miscellaneous' control registers.
It is full of registers. You don't just fiddle one thing one time,
then slam data in and out.
It's a very complex dual-port USART that will do Async, Bisync, SNA,
and more. We used them on the later models of COMBOARDs, though to a
fraction of their capability. Older models had a COM5025 sync serial
chip (because we modeled that section after some DEC sync serial
cards), so when we switched to the Z8530, we only ever used the
secondary port for async debugging.
One thing that complicated _our_ design was that we started using the
Z8530 very early in its evolution, so we were hanging either a 4MHz or
6MHz part off of an 8MHz 68000. We had to inject wait states (via
registered PALs and /DTACK, IIRC) _and_ we had to ensure we didn't jam
up the inner workings of the Z8530 by hitting the registers too fast.
We had NOPs in the driver between selecting and using the registers.
Perhaps 8MHz parts would be easier to use now.
Once we worked out what was needed, it was a solid, reliable chip, but
I will admit that our embedded application guys did have a few fits
trying to port front-end code from the older models that expected a
minimal-option simple chip like the COM5025.
-ethan