[Top] [All Lists]

Re: Things ...

To: caret@pyramid.com
Subject: Re: Things ...
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Date: 28 Jun 1993 14:20:25 +0800
Cc: riscy@pyramid.com
>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 

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 

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


<Prev in Thread] Current Thread [Next in Thread>