>> The TI340?0 video solution: From what I have read of the TI340?0, it
>> does its pixel stuff at the speed of its memory; that is, the speed
>> of bitblt is the bandwidth of its memory. In any windowing environment.
>> the speed of bitblt is the major determining factor in how fast it goes.
>> So, given this, the TI34020 is exactly twice the speed of the TI34010.
I've done a fair amount of 34010 software/hardware work in the past,
and this is from my (part fuzzy) memory, data book and experiences:
The 34010 Bitblt (or PIXBLT as they call it) cycles vary depending on
source/destination alignments and the BLT operation. For example, a
688x500 pixel BLT (approx size of my xterm) with PIXBLT XY, XY using
replace operation takes roughly 86000 machine cycles with best case
source and destination alignment. This translates to 57000 uSec or
57mS using 60MHz 34010, which isn't spectacular at all.
There are a few things with 34010 to note as well. 34010 doesn't do
fast page mode, so you can't really call the above 'at memory speed'.
34010 isn't that fast of a chip as far as clock speed goes.
Internally, every machine cycle is 1/4 of the clock, so it's actually
a heavy duty CISC chip that runs at 15MHz maximum. Also, there is a
limitation of 'power of 2' rule on the X-Y size of the bitmap area.
i.e, if a viewable screen is 640x480, you have to tell GSP to use
entire 1024x512 (closest power of 2 figures) worth of VRAM for
display. The un-viewable area cannot be used for code, since these
are little chunks along linear memory map.
On the other hand, this chip is really great for driving video with,
and everything is so nicely integrated. The completely programmable
video sync outputs, transparent (to programmers) VRAM transfer cycle
generation and built-in DRAM interface including refresh makes this
chip a really good choice to drive video with using VRAM.
Now, I'm fairly new to this mailing list, so please excuse me if I
missed some part of the thread. But getting 34010 to boot up from
scratch and make the code work reliably is a fair amount of work.
Since the chip hangs off of another CPU in this case, the 'host' CPU
has to support a lot of functionality such as downloading code to
34010 (essential for development), handle debug trace from 34010
(gotta have them printf's go somewhere) and so on. Personally, I've
had experiences of spending long, long, long LONG hours of trying to
debug 34010 code that crashes after certain combinations of
proprietary display list processing or font cache operation, and I
wouldn't recommend it to anyone.
Also, the real strength of 34010 comes from compact graphics specific
assembly code that can only be fully utilized by getting down to the
nitty gritty and writing the straight assembly. And gobs and gobs of
it if it was going to be X server running on it with decent speed.
It's not hard, since the chip handles a lot of things for you (such as
clipping, alignment and so on), and also since the address is counted
in bits and not bytes which sort of gives you the right perspective in
graphics programming. Even then, it may not compete well against late
model VGA's or accel chips with fast X server. The chip is just
getting outdated these days.... (and so is my expertise with this
chip, I suppose).
>> If we were to connect the VRAM (we should use VRAM rather than my
>> original suggestion) to the R3000, then we still have to generate
>> the cycles on the main bus to load the VRAM serial registers, and
>> have something generate the video sync signals.
Well, the transfer cycles wouldn't be generated on main bus, since it
is almost like a normal DRAM access cycle except that TR signal will
be applied before RAS* goes low. You can generate this after/inside
the DRAM (VRAM) interface rather than on the main bus.
>> While the TI34010 doesn't allow direct access to the VRAM from the
>> R3000, it does give us everything else. Unless we can get another
>> solution that does this with the VRAM connected to the R3000, then
>> I opt for this.
34010 allows host to access any part of it's local memory through it's
host control registers. This is really slow bandwidth, however.
Also, you can always have shared memory that hatls or waits 34010
during access by host (but with a lot of parts).
>> As for performance, the TI34010 probably competes fairly well with
>> things like the S3 chipsets, especially since some if not all of
>> the X-server can run on the TI34010.
I'm not too sure about that. I think its days are getting near the
end, especially with all the accel chips coming out.
Aki Atoji Unix, X, Networking and Embedded Realtime Consulting