Re: Video Coprocessor
On Tue, 4 Nov 1997, Dave Lowry wrote:
> Glad to see this list isn't dead!
>
> Could someone offer an explanation of why a JUMP in the video coprocessor
> takes "zero time"? Some sort of smart prefetch?
Exactly. But not "smart" in the sense that it is done only before jumps.
It is done always. Below is my understanding of what happens, which might
be not what actually happens.
The video coprocessor (VP) has two registers. Whatever is in the "shift
register" (SR) is being interpreted as video instructions (more or less).
VP tries to always have valid data in a "prefetch register" (PR).
Whenever the video instructions in the SR are finished, VP moves PR to SR,
generates a prefetch request to the memory coprocessor (MP) and continues
execution with the new SR.
Whenever the MP gets a chance -- at the end of the current memory
transaction of the stack processor (SP) -- it fetches the next video word
and puts it into PR. In the case it is a jump, MP generates an immediate
second memory access go get the video word at the new location. So, the
PR is sometimes filled with one memory access, sometimes with two.
Remember that during this time VP executes the instructions in SR under
the clocking of the external clock, which for NTSC happens to be 4x3.5X =
14.Y MHz. One video word has max four pixels, representing 2 periods of
the 3.5X MHz clock and is repeated at 1.7Z MHz, which is about 565 ns. So,
MP has 565 ns (@ 14.Y MHz) to service the request. If it succeeds, the
PR will be ready when it is needed, and there will be no glitch in the
video, thereby the "jump takes no time (in the analog output trace)"
statement.
The worst case scenario is the request to come at the beginning of a slow
IO (250 ns advertised), to fall to a video instruction, which is usually
off-page (150 ns advertised) which itself is an off-page video jump
(another 15 ns) for a total of 550 ns advertised. Therefore, there is
enough time to do this advertised.
Now, the advertised timings are achieved at something higher than 5V, say
5.3V, or 5.6V (don't run it over 6V, 'cause the signals off MuP21 are, say
.4V lower than Vcc and that goes to the rest of the system, assuming that
you have separate Vcc for MuP21, and you can ruin the other components).
At 5V the timings are slower, say +20 -- +40 ns for various memory
accesses, so 550 ns advertised is more like 620 ns @ 5V (I'm talking
MuP21H that is currently being sold by Dr. Ting). The result is MP to
coping on occasions with VP, which is expressed externally as "video
jitter."
There definitely are other "quirks" with MuP21H, mostly pronounced in the
video generation. I can be more specific if there is interest.
--
Penio Penev <Penev@pisa.Rockefeller.edu> 1-212-327-7423
