Menu
▾
▴
[Gc-linux-cvs] htdocs/xml/en news.xml,1.3,1.4 yagcd.xml,1.1,1.2
|
From: <mi...@pr...> - 2004-01-26 20:45:24
|
Update of /cvsroot/gc-linux/htdocs/xml/en In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18104/xml/en Modified Files: news.xml yagcd.xml Log Message: ... Index: news.xml =================================================================== RCS file: /cvsroot/gc-linux/htdocs/xml/en/news.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- news.xml 26 Jan 2004 00:47:56 -0000 1.3 +++ news.xml 26 Jan 2004 20:44:13 -0000 1.4 @@ -2,6 +2,11 @@ <?xml-stylesheet href="news.xsl" type="text/xsl"?> <news> <item> + <date>26 January 2004</date> + <title>Preliminary framebuffer code in CVS</title> + <text>drivers/video/gamecube.c can clear the screen and hopefully soon display text.</text> + </item> + <item> <date>25 January 2004</date> <title>Yet Another GameCube Documentation</title> <text>Groepaz has contributed 140 pages of compiled technical information on the GameCube. Read it <a href="docs/yagcd.html">here</a>.</text> Index: yagcd.xml =================================================================== RCS file: /cvsroot/gc-linux/htdocs/xml/en/yagcd.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -d -r1.1 -r1.2 --- yagcd.xml 26 Jan 2004 00:38:51 -0000 1.1 +++ yagcd.xml 26 Jan 2004 20:44:14 -0000 1.2 @@ -2359,11 +2359,14 @@ <tr><td align="center"><tt>0x80003100</tt></td><td align="center"></td><td align="center"></td><td>Start of code (usually)</td></tr> -<tr><td align="center"><tt>0x80003140</tt></td><td align="center"></td><td align="center"></td><td>Entry point (sometimes;)</td></tr> +<tr><td align="center"><tt>0x80003140</tt></td><td align="center"></td><td align="center"></td><td>Entry point (early SDK v1.0 applications)</td></tr> <tr><td align="center"><tt>0x81200000</tt></td><td align="center"></td><td align="center"></td><td>Load Address of the Apploader</td></tr> </table> - +<br /> +<br /> +note: of course the entrypoint of an application can be anything, those listed here +are just some typical examples. <div class="p"><!----></div> @@ -2397,7 +2400,11 @@ <tr><td align="center"><tt>0x817fe8c0</tt></td><td align="center"></td><td align="center"></td><td>ArenaHi - Top of Heap</td></tr> </table> - +<br /> +<br /> +note: the address of ArenaHi is not a constant, but should be set to the bottom +of the FST which is read from the DVD so its size depends on the application. the +value given here is just an example. <div class="p"><!----></div> @@ -12225,8 +12232,8 @@ 9.6</a>  AD16</h3> <div class="p"><!----></div> -AD16 is in the 2nd channel, as 0 device. Probably its used for debugging purposes. -AD16 is the 32-bit register, keeping bootrom "trace-step". +AD16 is on channel 2, as device 0. Probably its used for debugging purposes. AD16 +is the 32-bit register, keeping bootrom "trace-step". <div class="p"><!----></div> <h4><a name="tth_sEc9.6.1"> @@ -14329,6 +14336,9 @@ 13.10</a>  S3TC</h3> <div class="p"><!----></div> +WARNING: this section is screwed! any advice/corrections/help/etcblabla welcomed! +(thanx to <b>Aaron Kaluszka</b> for pointing this out) <br /> +<br /> S3TC is a compression method for textures. It basically gives you one more MIP level for free, with relatively small quality loss and a simple implementation in hardware. You basically store 2 colour values and then you have a few bits per pixel to interpolate @@ -14352,19 +14362,19 @@ 0 1 <br /> 2 3<br /> <br /> -Each block is made up of 8 words:<br /> +Each block is made up of 8 words. These 8 words represent 16 pixels using S3TC +compression.<br /> <br /> -RRRRRGGG - GGBBBBB? - rrrrrggg - ggbbbbb? - XXXXXXXX - XXXXXXXX - XXXXXXXX - XXXXXXXX<br /> +RRRRRGGG - GGGBBBBB - rrrrrggg - gggbbbbb - 00112233 - 44556677 - 8899UUVV- WWXXYYZZ<br /> <br /> -R = Primary Red<br /> -G = Primary Green<br /> -B = Primary Blue<br /> -r = Secondary Red<br /> -g = Secondary Green<br /> -b = Secondary Blue<br /> -? = Unknown (some kind of transparency?)<br /> -X = It appears the way that the two colors interact has something to do with the -last four bytes. It's almost like these bytes "shape" the block.<br /> +R = Color 0 Red<br /> +G = Color 0 Green<br /> +B = Color 0 Blue<br /> +r = Color 3 Red<br /> +g = Color 3 Green<br /> +b = Color 3 Blue<br /> +0 - 9, U - Z = Pixel color (2-bits each)<br /> +Colors 1 and 2 are interpolated from colors 0 and 3<br /> <br /> The tiles are 32 bytes each. Depending on the image format the width and height of the tiles will differ. A 16bit format (ie RGB5 or RGB4A3) will have a 4x4 pixel @@ -16307,8 +16317,18 @@ <tr><td align="center"></td><td align="right">cross-checking against the Source helped to make sure no bad errors sneaked in</td></tr> +<tr><td align="center"><b>Aaron Kaluszka</b></td><td align="right"><tt>meg...@ko...</tt></td></tr> + +<tr><td align="center"></td><td align="right">some image format info</td></tr> + <tr><td align="center"></td></tr></table> </center> <div class="p"><!----></div> +<br /><br />moreover, many thanks must go to everyone who helped making this document more consistant +and error free by proofreading and pointing out mistakes, in particular tmbinc, +org, hubb, Aaron Kaluszka, Skywalker, Jihad, xor37h, costis, CrowTrobo, mist ...<br /> +<br /> +<br /> +<tt><b>EOT</b></tt> <br /><br /><hr /></iparticle> |
