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