Re: talking to CTK 571 synthesizer
- From: Arno Wagner <me@xxxxxxxxxxx>
- Date: 13 Nov 2007 00:30:27 GMT
Previously Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx> wrote:
Arno Wagner <me@xxxxxxxxxxx> writes:
Previously Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx> wrote:
I've started reading the data sheets and have some fuzzy ideas about
what is going on.
Good ^^
Thanks. Here is my current state of confusion. The serial output
line (pin 12 of the game port) seems to be the same as the SOUT pin
of the UART. This output line comes from the Transmitter Shift
Register (TSR), which is not one of the 11 accesible
registers. There is a bidirectional arrow joining it to the
Transmitter Timing and Control Register (TTCR), also not an
accessible register, and a horizontal line, without arrows, joining
the TSR to the Transmitter Holding Register (THR), which *is* one of
the accessible registers. The THR is selected by address 0 with DLAB
0. However, there are actually two accessible registers selected by
address 0 with DLAB 0, the THR and the Receiver Buffer Register
(RBR). THR is for output and RBR is for input. So, there has to be a
way to tell the UART whether one is reading or writing. This is
apparently controlled by DOSTR-bar going high, for write, or
DISTR-bar going high, for reading. Now, the application information
on p.14 has the pins DISTR and DOSTR grounded and has DOSTR-bar tied
to the WR-bar pin on some unexplained device called the TCU and the
DISTR-bar tied to the RO-bar of the TCU. Since we know nothing about
the TSU except that it connects to the CPU through PHI1 and PHI2
(whatever they are), it is hard to know what to do from the CPU to
tell the UART to write or read via DOSTR-bar or DISTR-bar.
Well, unless you build hardware. On the software sie it is easy:
Do a port output to write and a port input to read. The former
will write the THR, while the latter will read the RBR.
Also not that for the UART variants with FIFOs, reading will
read and remove the last element in the input fifo, while writing
will add a new first element in the output FIFO. I think you
have to explicitely enable the FIFO on these devices.
On the other hand, DOSTR-bar and DISTR-bar in the diagram on p.3 don't show
arrows on DOSTR-bar and DISTR-bar pins, so maybe that means they are
bidirectional.
No. Probably an error in rendering.
And even if they are available for input, it is possible that
there are other ways to indicate a read or a write. For example, the
Interrupt Enable Register (IER, with address 1 and DLAB 0) has its lower
4 bits assigned to indicate various interrupts. Bit 1 is the Enable
Transmitter Holdering Register Empty Interrupt (ETBE), so maybe writing
to IER is part of the solution. Also, the Line Status Register (LSR,
selected by address 5) has its bit 5 indicating something about the
Transmitter Holding Register (THRE). And there might be others.
So, I'll look more closely at that kind of information tomorrow.
The interrupt stuff is important, unless you want
to do intense polling.
I'll read some more tomorrow. The registers are
selected by the three pins A2 A1 A0, which might be what you have in
mind for the offset, and by the most significant bit (called DLAB) of
the LCR register.
The offset is A0 + A1 * 2 + A2 * 4 (with AX being 0 or 1)
What does CPU register AX have to do with this?
This is "A<symbol here that can stand for 0,1,2>" ;-)
I don't know if that bit counts as one of the bits of
the offset.
No, only those addressable externally. The CPU will actually
apply the three LSBs in the out/in address operand directly
to A0,A1,A2. Also you can only write/read bytes, not words or
longer, since the UAR is actually a historic artefact from 8 bit
CPU times.
In addition to selecting the register with A0,A1,A2, there are also the
lines CS0,CS1,CS2 that select the UART itself when CS0+2*CS1+4*CS2=3.
These depend, according to the application figure on p.14, on address
lines 16 to 23 from the CPU.
These are actually used to place it at the base address.
I read a little about the various registers today. Tomorrow I'm going to
focus on reading the timing diagrams carefully on pp.8-12, in the hope
that this will make it easier to figure out the order in which things have
to be done in programs.
Sounds good. I made this journey to knowledge something like
20 years ago with only the data***. Very interesting, and
when you have really understood one of these datasheets,
you can understand most others with relatively low effort.
I read the timing diagrams for the write cycle and read cycle and found
them helpful. I'll read the transmitter, receiver and modem diagrams
tomorrow. There is something very basic I don't understand about the
UART and I don't know what it is yet.
You will find out.
I own a copy of Steve Ciarcia's book, Build Your Own Z80 Computer. Its
appendix C7 is a spec *** for a COM2502 and COM 2017 UART. It's much
simpler than the device we are discussing and the spec *** is much
shorter. However, it has one appealing feature, namely flow charts for
the receiver and the transmitter function.
Nice!
It still has terminology
such as Transmitter Shift Register. Anyway, I'm hoping that by comparing
this spec *** with the one we're discussing and also by studying the
flow charts, I might start to make sense of this.
Good idea. There is some universal functionality in there, and
some device specific. So firt understand the general princible,
and only then the details become important.
Arno
.
- Follow-Ups:
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- References:
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Arno Wagner
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Arno Wagner
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Arno Wagner
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Arno Wagner
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- From: Arno Wagner
- Re: talking to CTK 571 synthesizer
- From: Allan Adler
- Re: talking to CTK 571 synthesizer
- Prev by Date: Re: PCI a Bottleneck in USB 2.0 for Audio?, RT Os Issues
- Next by Date: Re: PCI a Bottleneck in USB 2.0 for Audio?, RT Os Issues
- Previous by thread: Re: talking to CTK 571 synthesizer
- Next by thread: Re: talking to CTK 571 synthesizer
- Index(es):