Subject: Re: Things ...

From: Pat Mackinlay <[email-masked]>
Date: 28 Jun 1993 14:20:25 +0800

>Lots of people think that the ISA bus should disappear.  True there seems
>to be a lack of chips that could help us here, however, I think that we
>could implement an ISA bus interface on one of the 3730 ports with a
>handfull of PALs and buffers.  The only thing that I can think of that

Ok, if you think this can be done as cheaply as you suggest, then it's 
probably the right thing to aim for.

>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

I don't think this is quite right. The R3k _will_ be able to access the 
34010's memory "directly" - through its host bus. In this mode of 
operation, the host processor can write "through" the 34010 and access the 
VRAM (and/or DRAM) attached to the 34010. This is how the host puts code 
into the 34k's memory. It will also allow us to use the video memory as a 
dumb framebuffer during the initial software stages. Yes, it _will_ be slow 
(the host bus is only 16 bit), but see my further comments below.

>This is not true.  Its fairly easy to attach different memory types
>to the 34010.

Ok, sorry, that wasn't what I really meant. What I was trying to say was 
that the 34010's memory (of whatever type) is used to hold _both_ its code 
_and_ its video data. What that would mean is that we could stick (say) 2M 
of VRAM on the chip, 1M for the video image, and 1M for code. Obviously, if 
at all possible, it would be better to use DRAM for code because its 
cheaper...

I read Jeremy's comments, but I'd have to say that I still support the idea 
of the 34010 as the graphics chip. The main advantage it buys us is that 
it's a very simple (and cheap) solution to the whole video system. You 
won't get any decent performance until the X server is residing on the 34k 
itself, but as I pointed out above, you _can_ treat it as a (slow) 
framebuffer until that point.

Jeremy is arguing that it would be faster to implement a straight 
framebuffer as the r3k is able to saturate memory bandwidth anyhow. This is 
true, and a straight framebuffer _would_ be faster - I'm not arguing that. 
What I'm saying is that a framebuffer is going to be harder and more 
expensive to implement than a 34k-based solution. If someone (Steve, 
where're the details on that NSC chip? <grin>) can come up with a chip that 
can generate the appropriate monitor timing signals and the "VRAM to DAC" 
transfers that is price competitive with the 34k solution, I'd say go for 
it, but for the moment, the 34k looks very attractive.

Rather more personal preference than anything else: Don't you just _love_ 
the idea of the X server running on its own CPU? It'd be the equivalent of 
having your own X terminal on board <grin>. No, it probably won't compete 
for speed with a well-designed framebuffer, but I think it's a very elegant 
solution.

Pat -- "There's only one thing left to do Mama, I got to ding a ding dang
	my dang a long ling long" (Jesus Built My Hotrod -- Ministry)
GCS d* -p+ c++ l++ m--- s+/- !g w- t- r

---

Date: Sun, 27 Jun 93 23:50:42 PDT

> (the host bus is only 16 bit), but see my further comments below.

Yeah, you can get access to any location in the 34k's address space
(including its own registers).  However, its not part of the R3k's
address space.  The 34k implements 4 locations in the r3k's address
space:  two are address registers, one is status, and the other is
data.  To copy a block of memory you place the start address in the
address register and then copy the data from/to the data register.
Doing a bitblt this way would be a pain, to say the least.

> for speed with a well-designed framebuffer, but I think it's a very elegant 

The 34010 will be around half the speed at doing bitblt's than the r3k;
the 34k can probably do other things faster (lines, circles) but they
don't matter.  As Pat says though, the 34k will take the load off the
r3k.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  [email-masked]
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

From [email-masked]  Ukn Jun 29 02:56:42 1993
Date: Mon, 28 Jun 93 23:35 PDT
From: [email-masked] (Aki Atoji)
To: [email-masked]
Subject: Re: Things ...
Status: RO

>> 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.

>>   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
           [email-masked]                   [email-masked]
---------------------------------------------------------------------------