From icculus at clutteredmind.org  Mon Apr 22 16:06:02 2002
From: icculus at clutteredmind.org (Ryan C. Gordon)
Date: Mon, 22 Apr 2002 16:06:02 -0400 (EDT)
Subject: test.
Message-ID: <Pine.LNX.4.33.0204221605530.32194-100000@gemini.verizon.net>


test.

--ryan.





From mrochuk at ee.ualberta.ca  Mon Apr 22 20:09:32 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 22 Apr 2002 18:09:32 -0600
Subject: Testing
Message-ID: <1019520572.15607.9.camel@lucid>

Hi.

Benj you on this yet?




From mrochuk at ee.ualberta.ca  Mon Apr 22 21:07:51 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 22 Apr 2002 19:07:51 -0600
Subject: How to get Quartus II not to crap all over everything
Message-ID: <1019524071.15609.15.camel@lucid>

Okay I managed to get Quartus to compile without moving any files in our
cvs tree: Here's how I have it setup

~/manticore/cvs/ <cvs tree>
~/manticore/quartus/ <all the quartus project stuff>

You just have to add all the vhd files in their individual directories,
except the package files which have no entities.  Then it should work. 
Seems to be anyway,

It doesn't even make files in all the cvs dirs.  So all the stuff we
need to compile is in there.  shiftreg_8x8 was forgotten but I added it
to the rasterizer/ dir.  This means we should be able to update cvs, and
just recompile.

I didn't even have to set up library dirs or anything.  Just need to
make sure the def files aren't added to the project and all the ones
with entities are.

Jeff



From mrochuk at ee.ualberta.ca  Tue Apr 23 19:06:29 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 23 Apr 2002 17:06:29 -0600
Subject: Hi
Message-ID: <1019603189.1654.18.camel@lucid>

Benj are you alive?  Did you get those messages I sent?

Andrew is also on this list now.

Jeff




From acling at ee.ualberta.ca  Tue Apr 23 19:06:17 2002
From: acling at ee.ualberta.ca (Ling Andrew Chaang)
Date: Tue, 23 Apr 2002 17:06:17 -0600 (MDT)
Subject: [manticore] Hi
In-Reply-To: <1019603189.1654.18.camel@lucid>
Message-ID: <Pine.HPX.4.21.0204231706100.14207-100000@eigen.ee.ualberta.ca>

hello??

are you alive

On 23 Apr 2002, Jeff Mrochuk wrote:

> Benj are you alive?  Did you get those messages I sent?
> 
> Andrew is also on this list now.
> 
> Jeff
> 
> 
> 



From mrochuk at ee.ualberta.ca  Tue Apr 23 19:15:05 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 23 Apr 2002 17:15:05 -0600
Subject: [manticore] Hi
In-Reply-To: <Pine.HPX.4.21.0204231706100.14207-100000@eigen.ee.ualberta.ca>
References: <Pine.HPX.4.21.0204231706100.14207-100000@eigen.ee.ualberta.ca>
Message-ID: <1019603705.3635.23.camel@lucid>

You look at any of the code yet?

On Tue, 2002-04-23 at 17:06, Ling Andrew Chaang wrote:
> hello??
> 
> are you alive
> 
> On 23 Apr 2002, Jeff Mrochuk wrote:
> 
> > Benj are you alive?  Did you get those messages I sent?
> > 
> > Andrew is also on this list now.
> > 
> > Jeff
> > 
> > 
> > 
> 
> 



From benjcarson at digitaljunkies.ca  Wed Apr 24 22:45:47 2002
From: benjcarson at digitaljunkies.ca (Benj Carson)
Date: Wed, 24 Apr 2002 20:45:47 -0600
Subject: testing
Message-ID: <001701c1ec03$4de9a7a0$0401010a@digitaljunkies.ca>

Please ignore this message, just testing....



From jmrochuk at ieee.org  Thu Apr 25 19:05:13 2002
From: jmrochuk at ieee.org (Jeff Mrochuk)
Date: Thu, 25 Apr 2002 17:05:13 -0600
Subject: Specs
Message-ID: <20020425230513.GA21185@lucid.digitaljunkies.ca>

For real world video specs it'd go something like this

Transistors (#)
Process Technology (um)
Chip Clock (MHz)
Memory Clock (MHz)
Memory Amount (MB)
Memory Bandwidth (MB/s)
Max Fillrate (pixels/s)
Max Triangle Rate (triangles/s)

The first two aren't really relevant to us, but we should be able to
figure out the others.

Jeff
-- 


From jmrochuk at ieee.org  Thu Apr 25 19:08:36 2002
From: jmrochuk at ieee.org (Jeff Mrochuk)
Date: Thu, 25 Apr 2002 17:08:36 -0600
Subject: Also
Message-ID: <20020425230836.GB21185@lucid.digitaljunkies.ca>

T & L is Transformation and Lighting.

Transformation has only recently been done in hardware I think.
Recent being Geforce/Radeon.

Also resolution support should be on there, and will be limited by Fill
Rate and Memory Bandwidth

Jeff
-- 


From mrochuk at ee.ualberta.ca  Thu Apr 25 20:10:14 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 25 Apr 2002 18:10:14 -0600
Subject: Information abound
Message-ID: <1019779814.3635.42.camel@lucid>

Alot of information on what graphics cards (At least the Geforce 2)
actually do in here:

http://www6.tomshardware.com/graphic/00q2/000427/index.html



From mrochuk at ee.ualberta.ca  Fri Apr 26 03:58:07 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 26 Apr 2002 01:58:07 -0600
Subject: How it goes down
Message-ID: <1019807887.3635.52.camel@lucid>

So I've been talking to some video guys.  Basically it works on 3
levels.

API (OpenGL, Direct3d), Drivers, and Hardware

Your API talks to your drivers, which tell the API what needs to be done
in software, and what can be done in hardware.

In traditional cards (pre Geforce or so) Texuring and Triangle Raster
are all that was done in hardware.  Color, lighting, and transfrom was
all done by the API. Recent cards have added hardware transform and
lighting, but no current game engines even use them yet.

We need to up our memory bandwidth and add texture support, and we've
got a voodoo.

Jeff




From benjcarson at digitaljunkies.ca  Fri Apr 26 17:03:52 2002
From: benjcarson at digitaljunkies.ca (benjcarson at digitaljunkies.ca)
Date: Fri, 26 Apr 2002 15:03:52 -0600
Subject: How it goes down
In-Reply-To: <1019807887.3635.52.camel@lucid> 
References: <1019807887.3635.52.camel@lucid>
Message-ID: <20020426210352.BB53188ED@ns1.digitaljunkies.ca>

Sounds good.  What do you think about the following goals then (sorta in 
order of importance): 

 - fix rasterizer to render all triangle orientations and add z-buffer
 - generalize sdram controller, vgaout, vgafifo_ctrl, rasterizer etc. for 
different resolutions and colour depths (probably requires maximizing memory 
throughput)
 - add normal support to the rasterizer
 - implement vertex lighting/texture mapping
 - add basic 2D support (lines, basic polygons, hardware cursor, etc.)
 - develop a PCI interface, drivers, etc.
 - figure out how to design a board... 

If a couple of us are working on it then we can modularize some of this to 
divide up the work.  In particular, I think we could split the rasterizer up 
into some sub-modules so that each module can be optimized independently. We 
can also easily parallelize part or all of it to double our pixel throughput 
then too.  I think the first few steps should be finished first before 
splitting everything up, because the underlying framework may change when we 
fix the memory controller and fifo. 

What do you think? 

Benj 


Jeff Mrochuk writes: 

> So I've been talking to some video guys.  Basically it works on 3
> levels. 
> 
> API (OpenGL, Direct3d), Drivers, and Hardware 
> 
> Your API talks to your drivers, which tell the API what needs to be done
> in software, and what can be done in hardware. 
> 
> In traditional cards (pre Geforce or so) Texuring and Triangle Raster
> are all that was done in hardware.  Color, lighting, and transfrom was
> all done by the API. Recent cards have added hardware transform and
> lighting, but no current game engines even use them yet. 
> 
> We need to up our memory bandwidth and add texture support, and we've
> got a voodoo. 
> 
> Jeff 
> 
> 
 


From jmrochuk at ieee.org  Fri Apr 26 18:15:24 2002
From: jmrochuk at ieee.org (Jeff Mrochuk)
Date: Fri, 26 Apr 2002 16:15:24 -0600
Subject: [manticore] Re: How it goes down
In-Reply-To: <20020426210352.BB53188ED@ns1.digitaljunkies.ca>
References: <1019807887.3635.52.camel@lucid> <20020426210352.BB53188ED@ns1.digitaljunkies.ca>
Message-ID: <20020426221524.GA27050@lucid.digitaljunkies.ca>

Yeah that looks pretty good to me, but I think we should move PCI up so
we can actually test on a PC once we get Z and raster working.  I'll
probably start working on SDRAM with in a week or so if you want to work
on the rasterizer.  Once we increase the memory bandwidth the z-buffer
should be easy to implement.

Jeff

On Fri, Apr 26, 2002 at 03:03:52PM -0600, benjcarson at digitaljunkies.ca wrote:
> Sounds good.  What do you think about the following goals then (sorta in 
> order of importance): 
> 
> - fix rasterizer to render all triangle orientations and add z-buffer
> - generalize sdram controller, vgaout, vgafifo_ctrl, rasterizer etc. for 
> different resolutions and colour depths (probably requires maximizing 
> memory throughput)
> - add normal support to the rasterizer
> - implement vertex lighting/texture mapping
> - add basic 2D support (lines, basic polygons, hardware cursor, etc.)
> - develop a PCI interface, drivers, etc.
> - figure out how to design a board... 
> 
> If a couple of us are working on it then we can modularize some of this to 
> divide up the work.  In particular, I think we could split the rasterizer 
> up into some sub-modules so that each module can be optimized 
> independently. We can also easily parallelize part or all of it to double 
> our pixel throughput then too.  I think the first few steps should be 
> finished first before splitting everything up, because the underlying 
> framework may change when we fix the memory controller and fifo. 
> 
> What do you think? 
> 
> Benj 
> 
> 
> Jeff Mrochuk writes: 
> 
> >So I've been talking to some video guys.  Basically it works on 3
> >levels. 
> >
> >API (OpenGL, Direct3d), Drivers, and Hardware 
> >
> >Your API talks to your drivers, which tell the API what needs to be done
> >in software, and what can be done in hardware. 
> >
> >In traditional cards (pre Geforce or so) Texuring and Triangle Raster
> >are all that was done in hardware.  Color, lighting, and transfrom was
> >all done by the API. Recent cards have added hardware transform and
> >lighting, but no current game engines even use them yet. 
> >
> >We need to up our memory bandwidth and add texture support, and we've
> >got a voodoo. 
> >
> >Jeff 
> >
> >
> 

-- 


From benjcarson at digitaljunkies.ca  Sat Apr 27 06:38:58 2002
From: benjcarson at digitaljunkies.ca (Benj Carson)
Date: Sat, 27 Apr 2002 04:38:58 -0600
Subject: License
Message-ID: <002f01c1edd7$bd412800$0401010a@digitaljunkies.ca>

Hey Jeff,

I've been reading the oc thread about the LGPL and this link popped up:

http://www.dsl.org/copyleft/dsl.txt

I think this is the license we should use.  The gist of it is basically free except that modifications to the code must
be made under a different name, the original authors must be cited and that the license be redistributed with any copy.
Otherwise it is prefectly legit for a company to use the design/software in a product *without* having to open up the
entire design.  I think this would be good, since people would be more inclined to use our design then, but we could
still get credit for our work...

What do you think?


I agree that PCI is probably pretty important, especially if we can get a third person working on it.  It can be
separated pretty well from what's going on already so it shouldn't matter too much what we end up changing while we fix
the rest of the design.


Benj



From mrochuk at ee.ualberta.ca  Sat Apr 27 13:34:17 2002
From: mrochuk at ee.ualberta.ca (Jeff Mrochuk)
Date: 27 Apr 2002 11:34:17 -0600
Subject: [manticore] License
In-Reply-To: <002f01c1edd7$bd412800$0401010a@digitaljunkies.ca>
References: <002f01c1edd7$bd412800$0401010a@digitaljunkies.ca>
Message-ID: <1019928857.3635.61.camel@lucid>

Just read it, looks pretty good.

We should put a small comment block on the top of our code.  For example
the GPL one looks something like:

/*
   Bitstream:  An OpenGL Space Action Game
   http://icculus.org/bitstream/

   Copyright (C) 2001, 2002 Jeff Mrochuk

   This file is part of bitstream.     Bitstream is free software; you
can redistribute it and/or modify it under the terms of the GNU General
Public License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

   Bitstream is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

   You should have received a copy of the GNU General Public License
along with Bitstream; if not, write to the Free Software Foundation,
Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Jeff Mrochuk
jm at icculus.org

*/
One one of the article links I saw that we should probably have this in
the source files:

-- Copyright ? YEAR AUTHOR; this information may be copied, distributed 
-- and/or modified under certain conditions, but it comes WITHOUT ANY 
-- WARRANTY; see the Design Science License for more details.

Maybe with some other stuff like the one above, and that should be
alright.

Jeff



From benjcarson at digitaljunkies.ca  Sat Apr 27 14:40:12 2002
From: benjcarson at digitaljunkies.ca (Benj Carson)
Date: Sat, 27 Apr 2002 12:40:12 -0600
Subject: [manticore] License
References: <002f01c1edd7$bd412800$0401010a@digitaljunkies.ca> <1019928857.3635.61.camel@lucid>
Message-ID: <000601c1ee1a$f702c9c0$0401010a@digitaljunkies.ca>

Yeah, that sounds good.  Whoever linked to that license in the thread mentioned that the license was approved by the
FSF, so that we can reference them like you're referencing the GPL in Bitstream.

Yeah, we definitely need a copyright in our files.  The Opencores header is pretty long if I recall, and may even
contain most of the license.  We could just include a LICENSE file like most software for bevity instead.

We should try and get a hold of Dr. Elliott this week so we can make arrangements to use a computer somewhere or to get
Quartus.  Hopefully he's back in town.

Also, they didn't have our cheques last night 'cause they needed to be signed.  Shayam will be on campus this summer so
he said he'd get them to us.  They only had one certificate, so they're gonna get another printed so we both can have
one.  Not only that, but they were 45 minutes late.  Just as organised as before...  All in all it wasn't too bad, just
a bit drawn out.

Benj

----- Original Message -----
From: "Jeff Mrochuk" <mrochuk at ee.ualberta.ca>
To: "Manticore" <manticore at icculus.org>
Sent: Saturday, April 27, 2002 11:34 AM
Subject: Re: [manticore] License


Just read it, looks pretty good.

We should put a small comment block on the top of our code.  For example
the GPL one looks something like:

/*
   Bitstream:  An OpenGL Space Action Game
   http://icculus.org/bitstream/

   Copyright (C) 2001, 2002 Jeff Mrochuk

   This file is part of bitstream.     Bitstream is free software; you
can redistribute it and/or modify it under the terms of the GNU General
Public License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

   Bitstream is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

   You should have received a copy of the GNU General Public License
along with Bitstream; if not, write to the Free Software Foundation,
Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

Jeff Mrochuk
jm at icculus.org

*/
One one of the article links I saw that we should probably have this in
the source files:

-- Copyright ? YEAR AUTHOR; this information may be copied, distributed
-- and/or modified under certain conditions, but it comes WITHOUT ANY
-- WARRANTY; see the Design Science License for more details.

Maybe with some other stuff like the one above, and that should be
alright.

Jeff