From tor@tss.no Mon Jun 28 10:09:19 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24757; Mon, 28 Jun 93 10:09:16 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18883; Mon, 28 Jun 93 01:09:08 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA20654; Mon, 28 Jun 93 01:08:55 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18861; Mon, 28 Jun 93 01:08:52 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <19523-0@ppenoni.uit.no>; Mon, 28 Jun 1993 10:08:42 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni19519; Mon, 28 Jun 1993 10:08:40 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA29682;
          Mon, 28 Jun 93 10:03:07 +0200
Message-Id: <9306280803.AA29682@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 10:03:06 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

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

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

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


Tor

 
From tor@tss.no Mon Jun 28 12:32:06 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25077; Mon, 28 Jun 93 12:31:58 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09849; Mon, 28 Jun 93 03:31:51 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA09116; Mon, 28 Jun 93 03:31:44 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA09841; Mon, 28 Jun 93 03:31:42 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20400-0@ppenoni.uit.no>; Mon, 28 Jun 1993 12:31:38 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20396; Mon, 28 Jun 1993 12:31:36 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA00338;
          Mon, 28 Jun 93 12:26:03 +0200
Message-Id: <9306281026.AA00338@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 12:26:01 +0200
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: riscy@pyramid.com
Subject: Re: Things ...
Status: RO
X-Status: 

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

Can't say I love it actually.. The Tandberg TDV 6230 runs an X-server
on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
almost anything.  The only thing that is slower on the PC is scrolling.
The TDV 6230 is certainly much slower than a 486 + S3.
Of course, the X-response on the PC gets real bad when compiling the
kernel at the same time! :-)

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

Tor



 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 13:38:44 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25240; Mon, 28 Jun 93 13:38:37 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20484; Mon, 28 Jun 93 04:38:30 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16447; Mon, 28 Jun 93 04:37:46 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20435; Mon, 28 Jun 93 04:37:40 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZX7Y264G6FUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 19:36:44 +0800
Date: 28 Jun 1993 19:36:44 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: tor@tss.no
Cc: riscy@pyramid.com
Message-Id: <01GZX7Y26E3CFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: riscy@pyramid.com
X-Vms-To: IN%"tor@tss.no"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


(Tor, this message is not specifically targetted at you, I'm just getting 
a little exasperated. Please don't take anything personally.)

>on the 34010 in 1024x768x1 (or x4), and it's slower than a 486+et4000 for
>almost anything.  The only thing that is slower on the PC is scrolling.
>The TDV 6230 is certainly much slower than a 486 + S3.

Am I talking to a brick wall? I _KNOW_ the 34k is slower - I thought 
I made that plain. If you can come up with a design that costs the same 
amount and gives better performance, go right ahead: I'm not hooked on the 
idea of using the 34010.

>Of course, the X-response on the PC gets real bad when compiling the
>kernel at the same time! :-)

I think that this is one small advantage of the "separate processor" 
approach, but not the most important for our particular application. 
Further on this point, I think that people will complain less about 
"graphics performance" when the main CPU is still free to run programs. 
The "two processor" approach should also make the machine more appealing to 
people who want to use the box as a server because users on the console 
will have less impact on the system performance. I suspect that most 
programs would run quite acceptably on the 34k - perhaps not benchmarking 
as fast as a dumb framebuffer solution, but certainly fast enough to be 
useful.

Side note: For those people who do use systems with 34010's, where 
exactly are the performance problems? Do you actually see the chip 
"painting" the screen, or is it just a general sluggishness? I suspect some 
of the performance problems could actually be due to the fact that X 
terminals are usually diskless, and the I/O overhead dominates the actual 
graphics performance. This would not be an issue with a "local" 
implementation.

People: _PLEASE_, if you can come up with a practical alternative for a 
video system (I know you're out there Steve <grin>), speak up now. It 
_would_ be much better to use a dumb framebuffer attached to the CPU, but I 
fear that the extra logic required to generate monitor signals and clock 
the data out of the VRAM at the right speed would be a 

To try and summarize my opinion, I'd just like to say that most programs 
(that I deal with) are not limited by the speed of the X server. Usually, 
the limitations are on the system I/O performance. I think that using a 
separate CPU to do graphics will make our system less complex (ie: cheaper) 
while still providing perfectly acceptable graphics performance. Not only 
that, but it makes the system a bit more "interesting", from a hobbiest's 
perspective (I mean, what's the point of doing it if it's not going to be 
interesting <grin>). If someone comes up with a cheap and simple 
alternative to the 34k solution, I'd be very happy to use it, but so far,
no one has, and the 34k is the best choice in my mind.

As for the guy that said he'd be willing to pay $1200 for the system, I 
can't agree. In my mind, once you get over the US$800 mark, you'll be much 
better off with a fully "commercial" system. As Neil mentioned before: if 
all you want is a faster PC, by all means, go and buy one. I know it looks 
like I'm harping on the point, but the price and complexity of this system 
are the factors which will decide its fate.

Again, I hope we've seen the end of the integer vs FP argument: that can be 
sorted out when the time comes. It's much more important to fill in the 
other parts of the system right now. Please don't bring it up again.

[...At the risk of repeating myself (again): If you're going to "knock" the 
34k solution, please make sure you have a viable alternative...]

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

 
From tor@tss.no Mon Jun 28 14:04:52 1993
Return-Path: <tor@tss.no>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA25298; Mon, 28 Jun 93 14:04:48 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA25086; Mon, 28 Jun 93 05:04:39 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18904; Mon, 28 Jun 93 05:04:29 -0700
Received: from benoni.Uit.No 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA24974; Mon, 28 Jun 93 05:04:27 -0700
Received: from benoni by ppenoni.uit.no with SMTP (PP) 
          id <20989-0@ppenoni.uit.no>; Mon, 28 Jun 1993 14:04:05 +0000
Received: from unas.tss.no 
          by benoni.uit.no (5.65+IDA/Babel-1.15/ABaa-1.2/Ultrix) 
          id AAbenoni20985; Mon, 28 Jun 1993 14:04:00 +0200
Received: by unas.tss.no (4.0/ABaa-1.3mini) id AA01676;
          Mon, 28 Jun 93 13:58:27 +0200
Message-Id: <9306281158.AA01676@unas.tss.no>
From: tor@tss.no (Tor Arntsen)
Date: Mon, 28 Jun 1993 13:58:25 +0200
In-Reply-To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au> "Re: Things ..." (Jun 28, 7:36pm)
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
Cc: riscy@pyramid.com
Status: RO
X-Status: 

Pat Mackinlay wrote:
>(Tor, this message is not specifically targetted at you, I'm just getting 
>a little exasperated. Please don't take anything personally.)
No problem.. :-)

[a lot deleted]
>Side note: For those people who do use systems with 34010's, where 
>exactly are the performance problems? Do you actually see the chip 
>"painting" the screen, or is it just a general sluggishness? I suspect some 
>of the performance problems could actually be due to the fact that X 
>terminals are usually diskless, and the I/O overhead dominates the actual 
>graphics performance. This would not be an issue with a "local" 
>implementation.

Good point.  If I get the time I will fire up that system to see if I can
make better conclusions.  But don't let that put you on hold guys :-)

[more deleted]
>[...At the risk of repeating myself (again): If you're going to "knock" the 
>34k solution, please make sure you have a viable alternative...]
                                           ^^^^^^^^^^^^^^^^^^
Well, I don't have any!  I will probably not have any time available for a 
long time to dig into it either, so please just take those postings from me
as 'user reports', I certainly don't want to make any claims of how it
shall be done.

I still think this board will be fun..
Tor	(tor@tss.no)


 
From caret@pyramid.com Mon Jun 28 07:32:34 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24148; Mon, 28 Jun 93 07:32:26 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20718; Sun, 27 Jun 93 22:31:45 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA07240; Sun, 27 Jun 93 22:31:20 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306280531.AA07240@sword.eng.pyramid.com>
Subject: Things ...
To: riscy@pyramid.com
Date: Sun, 27 Jun 93 22:31:20 PDT
Cc: paul@sw.oz.au
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 

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
would be hard (if not impossible) is implementing the -MASTER signal.
My current guess is about $20 worth of components plus the cost of the
ISA sockets.  The big loose here is the relatively large amount of
time required to design it.

Some people suggested adding an ISA bus at the end of a SCSI cable.
While this has merit, maybe as another product, I don't think its
suitable here.  Note the about price guess.  Also, whatever the cost of
somplementing ISA, it will be more to do it this way.

As for implementing another new an improved slow peripheral bus,
what's the point?  There would be nothing to connect to it.
A partial ISA bus could be done just as easily.

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.

The video sub-system must include memory, something to read it and encode
it into a serial bit stream, a Digital-to-Analog converter (RAMDAC),
and something to generate timing signals.  Memory is easy.  The RAMDAC
is easy.  The stuff to tie this together is to topic of discussion.
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.

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.

Also note that the TI34010 is a CPU in its own right, and it does have
access to the VRAM.  Also note that I may be able to get binaries
for a C compiler system for the TI34010 to run on linux for a small
fee.

The TI34020 is probably not a viable option for two reasons: i)
Cost.  Last I checked it was >$100; ii) Its interface to the host
CPU is now *much* more complicated.

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.

Someone suggested using the Zilog SCC chips for serial.  I agree in
principal.  They have the problem that they are much more difficult
to program right because of various bugs, but they allow a much
richer set of options for serial format (can to various SYNC modes).

Little vs Big endian mode:  The R3000 CPU can do both.  The selection
is done at reset time and cannot be changed later.  As for implementing
logic to allow the OS to reset just to change endian mode, I think this
is unwise; apart from the extra logic, how long does a reset take
in comparison to a system call?

Keyboard controller:  The format of the keyboard interface is fairly
well defined.  I know of one implementation of a peripheral that
read the keyboard using two PALs.  Problem with that implementation
is that it didn't ahndle all of the AT keyboard stuff (such as the
CAP/NUM/SCROLL LEDs).  We can always program our own 8041/8051.
Downloading code to these though is probably not an option.  I will
call AMI.

The issue of how to mount the extra connectors (ehternet, SCSI, etc).
SCSI is easy:  we provide a 50-pin header on the motheroard; that is:
no external access provided by default.  Video and ethernet are
problems.  Personally I would mount the video in one the 25-pin
serial holes provided on most boxes (a hack) and mount the ethernet
connector in a similar way (also a hack).  Another solution is
to get a bracket made to handle both of these and screw it into
an unused slot opening.  I am thinking that we should only provide
about 4 ISA connectors anyhow.  In this thinking I have not
thought of having more than one type of ethernet connector.

Pat says:
> I was assuming this. I've since found out a bit more about the 34k. 
> Basically, the chip has access to one memory bank. This bank may be either 
> DRAM or VRAM, and is used to store both the chip's code and the video 
> image. The host has access to all of this memory through an 8 or 16 bit 

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

Jeremy Gurgles:
> Parallel is important.  There is nothing more useful than being able to
> flash LEDs when nothing else works (either cause something is very broken
> or because you're in the early stages of writing monitor code).

I also think its important, though with simple enough serial ports
it may not be needed in the way you suggest.  I'd just be happy to
plug a parallel card into the ISA bus.  Addingeasy access LEDs is a
good plan though.  I think PALs have enough omf to drive them, and
there should be at least one output left on a PAL...

Sound?  Truly simple sound is to use the IBM method.  Not quite as
simple sound is the MAC method.  Maybe a handfull of resistors for
the DAC and a few resisters and capacitors for a simple filter
should be enough; we are not trying to compete with SoundBlasters
after all.  Anyone done this kind of DAC?  Isn't it text book stuff?

I'm back from Usenix.  I'll be spending this week getting information
from manufacturers about all these chips people are suggesting.
-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From SMACKINLA@cc.curtin.edu.au Mon Jun 28 08:23:23 1993
Return-Path: <SMACKINLA@cc.curtin.edu.au>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24226; Mon, 28 Jun 93 08:23:12 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29974; Sun, 27 Jun 93 23:22:27 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA11990; Sun, 27 Jun 93 23:22:19 -0700
Received: from cc.curtin.edu.au 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA29962; Sun, 27 Jun 93 23:22:03 -0700
Received: from cc.curtin.edu.au by cc.curtin.edu.au (PMDF #3256 ) id
 <01GZWX8I5RHMFUMLVJ@cc.curtin.edu.au>; Mon, 28 Jun 1993 14:20:25 +0800
Date: 28 Jun 1993 14:20:25 +0800
From: Pat Mackinlay <SMACKINLA@cc.curtin.edu.au>
Subject: Re: Things ...
To: caret@pyramid.com
Cc: riscy@pyramid.com
Message-Id: <01GZWX8I5RHOFUMLVJ@cc.curtin.edu.au>
X-Envelope-To: caret@pyramid.com, riscy@pyramid.com
X-Vms-To: IN%"caret@pyramid.com"
X-Vms-Cc: R3KPC,SMACKINLA
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT
Status: RO
X-Status: 


>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

 
From caret@pyramid.com Mon Jun 28 08:53:31 1993
Return-Path: <caret@pyramid.com>
Received: from gossip.pyramid.com by dutecai.et.tudelft.nl (4.1/1.34JP)
          id AA24525; Mon, 28 Jun 93 08:53:19 +0200
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA06141; Sun, 27 Jun 93 23:52:46 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15136; Sun, 27 Jun 93 23:52:30 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9306280652.AA15136@sword.eng.pyramid.com>
Subject: Re: Things ...
To: riscy@pyramid.com
Date: Sun, 27 Jun 93 23:52:30 PDT
X-Mailer: ELM [version 2.3 PL11]
Status: RO
X-Status: 


 
From caret Sun Jun 27 23:50:42 1993
Subject: Re: Things ...
To: SMACKINLA@cc.curtin.edu.au (Pat Mackinlay)
Date: Sun, 27 Jun 93 23:50:42 PDT
In-Reply-To: <01GZWX8I5RHOFUMLVJ@cc.curtin.edu.au>; from "Pat Mackinlay" at Jun 28, 93 2:20 pm
X-Mailer: ELM [version 2.3 PL11]
Status: O
X-Status: 

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

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.

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

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:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845

 
From aki@akix.cts.com  Ukn Jun 29 02:56:42 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA00797; Tue, 29 Jun 93 02:56:40 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17316; Mon, 28 Jun 93 23:54:18 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28381; Mon, 28 Jun 93 23:54:18 -0700
Received: from crash.cts.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17312; Mon, 28 Jun 93 23:54:12 -0700
Received: from akix by crash.cts.com with uucp
	(Smail3.1.28.1 #15) id m0oAZZl-0000kRC; Mon, 28 Jun 93 23:53 PDT
Received: by akix.uucp (/\==/\ Smail3.1.21.1 #21.2)
	id <m0oAZI3-0002ELC@akix.uucp>; Mon, 28 Jun 93 23:35 PDT
Message-Id: <m0oAZI3-0002ELC@akix.uucp>
Date: Mon, 28 Jun 93 23:35 PDT
From: aki@akix.cts.com (Aki Atoji)
To: riscy@pyramid.com
Subject: Re: Things ...
In-Reply-To: <9306280531.AA07240@sword.eng.pyramid.com>
References: <9306280531.AA07240@sword.eng.pyramid.com>
Status: RO
X-Status: 


>> 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
           aki@akix.cts.com                   crash!akix!aki@trout.nosc.mil
---------------------------------------------------------------------------

 
