Subject: Re: High serial port (output) speeds
To: Michael Lorenz <ml@rz.uni-potsdam.de>
From: Bill Studenmund <wrstuden@nas.nasa.gov>
List: port-sparc
Date: 10/23/1999 17:09:18
On Sat, 23 Oct 1999, Michael Lorenz wrote:
> Hmm, some years ago I did some lowlevel programming on a Z80 system which of
> course used the Z80 SIO as serial controller. As far as I remember the Z8530 is
> just a crippled Z80 SIO OK, the Z80 SIO was able to use half it's clock as
The SCC is a bit more. :-) The SCC doesn't have all the features of the
SIO (as you describe them), but it does have a built in baud rate
generator. And the 8530 doesn't have the Zilog multiplexed bus business.
:-)
> So stands the question: what are the read differences between the Z8530
> and the Z80 SIO ? SInce the SPARC runs at a far higher clock than the
> Z80 it should be able to handle a much higher interrupt frequency ( the
> Z80 SIO has 4 bytes receive buffer and used 4 interrupts per channel ).
> I don't know anything about
The SCC has a three-byte input fifo.
> how a SPARC handles interrupts so please don't laugh. The Z80 interrupt
> mode 2 used a single IRQ line, when it goes high the processor does an
> "interrupt acknowledge cycle" in which it asked the chip which issued
> the interrupt for a "vector" which was used as an offset in a table of
> jump addresses, so interrupt sharing was nothing to worry about with a
> Z80 since it could handle 128 different interrupt sources without any
> headache... Could a SPARC do something like this to use the status
> interrupts of the Z8530 ? ( when they didn't cripple the Z80 SIOs
> interrupt system... ) the 4 interrupts it could generate were low water
> in send buffer, high water in receive buffer, byte received and error as
> far as I remember.
The vectoring isn't really useful. sparcs (and macs too) don't generate
these interrupt acknowledgement cycles. We could read the vectored
interrupt which would have been reported if we had the Zilog interrupt
business, but we don't. Instead there's a status byte which has 3 bits per
channel: receive, transmit, and status. The current driver will address
all pending interrupt status before returning. With vectoring, we'd have
to repeatedly sample the vector. :-)
Take care,
Bill