gbadev.org forum archive

Hello everyone,

my Maya Display List Exporter is up and running (I'll release a version once I get an answer to this question ! I want to make sure I'm not doing something wrong...)

If I export a triangle, it works fine. I can rotate it on the DS hardware and it works great. (I'm not using an emu for these tests)

I downloaded the latest version of devkitpro about a week ago, so I think I'm up to date.

If I export anything more than a triangle (i.e. a quad, i.e. two triangle, a cube, etc...) the object rotates normally, then the geometry gets distorted and then the DS crashes.

Here are some examples of some display lists generated by my exporter... can anyone see anything wrong ?

Triangle (this one works !)

Code:

u32 callList[] =
{
9,
FIFO_COMMAND_PACK(FIFO_BEGIN, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
GL_TRIANGLE,
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_END, FIFO_NOP, FIFO_NOP, FIFO_NOP),
};

Quad (crashes after a half second...)

Code:

u32 callList[] =
{
18,
FIFO_COMMAND_PACK(FIFO_BEGIN, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
GL_TRIANGLE,
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_END),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
};

Cube (also crashes...)

Code:

u32 callList[] =
{
108,
FIFO_COMMAND_PACK(FIFO_BEGIN, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
GL_TRIANGLE,
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(inttov16(1),0),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_END, FIFO_NOP, FIFO_NOP),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(inttov16(-1),0),
};

Essentially all I've done is modified the code for the Display List 1 example, and included the .h file... I also added a zoom function with the shoulder buttons... here's the source in case anyone's interested...

Code:

#include <nds.h>

#include "callList.h"

int main()
{

float rotateX = 0.0;
float rotateY = 0.0;
float zoom = -1;

powerON(POWER_ALL);

//set mode 0, enable BG0 and set it to 3D
videoSetMode(MODE_0_3D);

//this should work the same as the normal gl call
glViewPort(0,0,255,191);

glClearColor(255,0,0);
glClearDepth(0x7FFF);

while(1)
{

   //any floating point gl call is being converted to fixed prior to being implemented
   gluPerspective(35, 256.0 / 192.0, 0.1, 40);

   gluLookAt( 0.0, 0.0, 1.0,    //camera possition
            0.0, 0.0, 0.0,    //look at
            0.0, 1.0, 0.0);    //up



   glPushMatrix();

   //move it away from the camera
   glTranslate3f32(0, 0, floattof32(zoom));

   glRotateX(rotateX);
   glRotateY(rotateY);

   glMatrixMode(GL_TEXTURE);
   glIdentity();

   glMatrixMode(GL_MODELVIEW);

   //not a real gl function and will likely change
   glPolyFmt(POLY_ALPHA(31) | POLY_CULL_NONE);

   scanKeys();

   u16 keys = keysHeld();

   if((keys & KEY_UP)) rotateX += 3;
   if((keys & KEY_DOWN)) rotateX -= 3;
   if((keys & KEY_LEFT)) rotateY += 3;
   if((keys & KEY_RIGHT)) rotateY -= 3;

   if((keys & KEY_R)) zoom -= 0.1;
   if((keys & KEY_L)) zoom += 0.1;

   glCallList(callList);

   glPopMatrix(1);

   glFlush();

}

return 0;
}//end main

Help ! Thanks !

Last edited by ikaris on Thu Jun 22, 2006 5:44 pm; edited 1 time in total

Interesting :)

How do you calculate the first number (the length right ?) in the list ?

I'm not sure at all but intuitively I'd say that
the lenght should be 15 instead of 18 for the Quad...

/Valmond

Hi Valmond !

Different values are worth a different amount for the u32 number...

vertices are worth 3, (so, triangle 3 * 3 = 9) color are worth 1, texture are worth 2...

The thing is, if you get the number wrong, it object doesn't even show up on the screen... so I know that the number is right since its actually rendering the quad (if only for half a second :) )

Any ideas ? Is there any documentation on this somewhere ?! Is this a Nintendo standard, an OpenGL standard, or someone else's ?

ikaris wrote:

Any ideas ? Is there any documentation on this somewhere ?! Is this a Nintendo standard, an OpenGL standard, or someone else's ?

there is, if you are allowed [...] to buy an official nitro devkit, you get one ;)

maybe you could start making a doc if you know enough about the topic. that would be really cool :)

Hey, silent !

I would like to make a doc, once I figure this out !

And, of course, make my Maya Display List exporter public !

I'll keep you posted !

Here's a video showing first, a working triangle, and then, the crashing quad...

http://www.youtube.com/watch?v=O-QsbLwnoYE

I can't see an error in the code you posted

Do you utilize any IRQs that might interfere?
Could it be that the key-read hangs up (probably with the ARM7)? Test this by adding an "auto rotate" that does not check for keyinput
_________________
GBAMP Multiboot

I know *nothing* about DS programming, but one thing did stand out to me immediately. At the end of your first example, you have this:

Code:

FIFO_COMMAND_PACK(FIFO_END, FIFO_NOP, FIFO_NOP, FIFO_NOP),

But the other examples don't. Perhaps that's the reason? Also, do the Begin/End commands need to be included in the length?

I have a working exporter for MisfitModel3d. If you haven't solved this by tonight I'll post some test files when I get home.

Did they re-enable the DMA copy in glCallList()? That might be causing trouble.

Thanks for your comments, everyone !

I will try to add the auto-rotate instead of the key input and see what happens... !

Nope... making the rotation automatic doesn't help.

It rotates for a half second, then freaks out.

I should mention that the teapot sample works fine for me... maybe I should use my object in there instead of Display List 1 ?

So its for sure the arm9 code that hangs up.

The teapot is worth a try, but i'd get back to your own code when it works to find the error.
_________________
GBAMP Multiboot

Putting my callList into the teapot example crashes as well...

so it must be my FIFO_COMMAND_PACK data.

I'm working on a few angles, and I'll let you all know once I've figured it out.

Have you tried changing the value from 18 to 15? I'm almost certain that is the problem, a display list overflow. It is definately possible to render the display list without the correct length, but from my experience, it gets fucked up after a while.

I would try it myself, but I'm sitting in an internet caf? of an all inclusive hotel in Andalucia at the moment (BRAG BRAG BRAG). :P
_________________
"no offense, but this is the gayest game ever"

Just tried something like that :)

Thought that maybe you have to put the colors in so
I did that, and calculated the length according to ikaris

Code:

u32 callList[] =
{
24,
FIFO_COMMAND_PACK(FIFO_BEGIN, FIFO_COLOR, FIFO_VERTEX16,FIFO_COLOR),
GL_TRIANGLE,
RGB15(31,0,0),
VERTEX_PACK(inttov16(-1),inttov16(-1)),VERTEX_PACK(0,0),
RGB15(0,31,0),

FIFO_COMMAND_PACK(FIFO_VERTEX16,FIFO_COLOR, FIFO_VERTEX16, FIFO_COLOR),
VERTEX_PACK(inttov16(1),inttov16(-1)), VERTEX_PACK(0,0),
RGB15(0,31,31),
VERTEX_PACK(inttov16(0),inttov16(1)), VERTEX_PACK(0,0),
RGB15(0,0,31),

FIFO_COMMAND_PACK(FIFO_VERTEX16,FIFO_COLOR, FIFO_VERTEX16,FIFO_COLOR),
VERTEX_PACK(inttov16(-1),inttov16(-1)), VERTEX_PACK(0,0),
RGB15(0,31,31),
VERTEX_PACK(inttov16(0),inttov16(1)), VERTEX_PACK(0,0),
RGB15(0,0,31),

FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_NOP, FIFO_NOP,FIFO_END),
VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(0,0),
0,0,0,0,0,0
};

Well, with the 0,0,0,0,0 at the end (dont know how many is needed :p)
it works, without it doesn't so maybe the problem is there...

/Valmond

It seems like I was indeed correct. Valmond, could you try removing all the zero's and changing the 24 to 23?
_________________
"no offense, but this is the gayest game ever"

setting the length to less (22 for example) doesn't work (no crash, no poly),
setting it to 24 and add at least one zero works, without one zero it crashes.

works (from example above)

Code:

... VERTEX_PACK(inttov16(-1),inttov16(1)), VERTEX_PACK(0,0),
0
};

HTH

/Valmond *going to eat*

My exporter does export vertex colors and tex coords, but I simply didn't add them to make the examples simpler.

Anyway, I just tried setting it to 23 and...

it WORKS !!!!

So I just have to find out why 23 works, and how to adjust my calculations...

Once I figure it out, I'll post my Maya Exporter !

Thanks guys !

So, my logic is: take the number of triangles and subtract one...

So I tried making a cube, which gives me 144...

A cube has 12 triangles.

So, I tried subtracting 11 from 144, so I put 133 into the .h file...

aaaaand....

it didn't work :(

WTF !

ikaris wrote:

My exporter does export vertex colors and tex coords, but I simply didn't add them to make the examples simpler.

Anyway, I just tried setting it to 23 and...

it WORKS !!!!

So I just have to find out why 23 works, and how to adjust my calculations...

Once I figure it out, I'll post my Maya Exporter !

Thanks guys !

The 23 because you send 23 dataparts. Just count entries of that list after this number.

- 4 Command Packs
- 1 glType (GL_TRIANGLE)
- 6 color data
- 12 vertex Packs
====
23 Data chunks
_________________
GBAMP Multiboot

I'll try modifying my exporter with this in mind...

Woooohoooo !

Cube is working, no problem.

To paraphrase Max:

- Each COMMAND_PACK is worth 1
- The GL_TRIANGLE is worth 1
- Each vertex is worth 2
- Each vertex color is worth 1
- (I will assume) each UV is worth 1 (I'll test that out later)

I'll clean up my exporter, add some //comments, and let it loose into the world this evening !

Nice !

Here is the code for glCallList (copied from the sourceforge CVS):

Code:

//---------------------------------------------------------------------------------
//Display lists have issues that need to resolving.
//There seems to be some issues with list size.
//---------------------------------------------------------------------------------
GL_STATIC_INL void glCallList(u32* list)
//---------------------------------------------------------------------------------
{
u32 count = *list++;

while(count--)
GFX_FIFO = *list++;

//this works sometimes??
// DMA_SRC(0) = (uint32)list;
// DMA_DEST(0) = 0x4000400;
// DMA_CR(0) = DMA_FIFO | count;
//
// while(DMA_CR(0) & DMA_BUSY);

}

A display list is simply an array of 32bit values.
The first element of the array is a count of the number of 32 bit values following it. This count causes glCallList to copy that number of 32 bit values into the 3D fifo.
Each of the following command/data values take up 32 bits (even if they could be stored in less than that - 16bits for a colour). Since a vertex is represented by 3 16bit values (x, y and z) it is placed into a list with two VERTEX_PACK elements (one for the x and y and the other for z and 0 padding).
Therefore, for each element (i.e. COMMAND_PACK, VERTEX_PACK, RGB15 etc.) you add to the array add one to the count value.

Alright, people, I'm SO close to releasing this exporter... but I still have a problem !

When I create and then export a sphere larger than 8 radius, it's all distorted when I load it up into my example. However, anything smaller than 8 x 8 x 8 is fine...

The problem is that most objects lose a LOT of detail if you can only have 16 fixed-point positions per axis :)

I've gone over my export code a million times and there's nothing wrong with the values being pulled out of the geometry.

The code is exactly like I had in the first post:

Code:

u32 callList[] =
{
18,
FIFO_COMMAND_PACK(FIFO_BEGIN, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16),
GL_TRIANGLE,
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
FIFO_COMMAND_PACK(FIFO_VERTEX16, FIFO_VERTEX16, FIFO_VERTEX16, FIFO_END),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(0),0),
VERTEX_PACK(inttov16(-1),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
VERTEX_PACK(inttov16(0),inttov16(0)), VERTEX_PACK(inttov16(-1),0),
};

Just imagine the values being under -8 or over 8...

Does the fact that I'm using VERTEX16 and inttov16 related to this ? I thought the 16 was for bits of precision, not actual integer values :)

Any ideas ?

Have a look at this thread...wierd?
http://forum.gbadev.org/viewtopic.php?t=6046
_________________
"no offense, but this is the gayest game ever"

The fixed point type used by the hardware can not express values greater or equal to eight iirc. A look in the definition of inttov16 should clarify that.

So just scale your model down until it matches your desires.

[edit]
From libnds:

Code:

typedef short int v16; // vertex 4.12 fixed format
#define inttov16(n) ((n) << 12)

in 2-complement, that reaches from -8 to +7,999755859375 in steps of 0,000244140625
_________________
GBAMP Multiboot

...

you have GOT to be kidding me...

That makes me want to go back to Immediate Mode from Call Lists...

this sucks!

ikaris wrote:

...

you have GOT to be kidding me...

That makes me want to go back to Immediate Mode from Call Lists...

this sucks!

Its the same in immediate mode
_________________
GBAMP Multiboot

Steps of 0,000244140625... but that gets rounded to a whole number, no ?

So its as good as -8 to 8... right ?

Mighty Max wrote:

Its the same in immediate mode

I said that because its easier to write an exporter that translates values over 8 if its in Immediate Mode...

nah, its not rounding if you don't round yourself.

inttov16 only uses full numbers (int)

but you can do this conversation for float as in the following example (note: its not optimized)

Code:

float coordinate = 2.3375f ;

v16 fixedPointCorrdinate = (v16)(coordinate * 4096.0f) ;

edit: actually there is a floattov16 allready defined.
_________________
GBAMP Multiboot

Mighty Max wrote:

edit: actually there is a floattov16 allready defined.

ya but if you compile with it, it says its deprecated...

ikaris wrote:

Mighty Max wrote:

edit: actually there is a floattov16 allready defined.

ya but if you compile with it, it says its deprecated...

Are you sure that you are using floattov16 and not floatov16 (note the extra 't'). The latter versions (single 't') of all macros are deprecated.

As for the -8 to 8 range of the fixed point system, it does not really matter as the models can be scaled at render time, so during the export scale all vertice to fit inside the 16x16x16 cube (maybe include the scaling factor in the model description).
If all the models use the same scaling factor then there is no additional cost, i.e. you do not have to change the model matrix between different models. The scaling factor can easily be adjusted (before compile time) if a user of your exporter has models with different factors.

thanks max you really know your stuff ! I ignorantly thought the single and double "t" were the same...

now it works great with the float ! one step closer to releasing my exporter... the models coming out of it look great now...

You got 65536 steps, which eventually fit a pixel position on screen at the end :)

I use this in my XFile converter :

Code:

n=(int)(vert[i].get(j)*4096.0f); //<-one x,y or z from a vertex
fputc(n&255,f);
fputc(n>>8,f);

where the input is a float and the output is a 16bit int (to a file), and it works ok.

BTW I also scale the (in this case 3DSMax) mesh by 0.01

[edit]just read the page 3, most things are already explained, gotta stop posteing before the morning coff? :p[/edit]
/Valmond

gbadev.org forum archive

DS development > Display List Experts: Apply within ! (now with a video !)

#88960 - ikaris - Thu Jun 22, 2006 2:49 pm

#88966 - Valmond - Thu Jun 22, 2006 3:51 pm

#88976 - ikaris - Thu Jun 22, 2006 5:07 pm

#88979 - silent_code - Thu Jun 22, 2006 5:32 pm

#88980 - ikaris - Thu Jun 22, 2006 5:35 pm

#88981 - ikaris - Thu Jun 22, 2006 5:45 pm

#88985 - Mighty Max - Thu Jun 22, 2006 6:06 pm

#88989 - edwdig - Thu Jun 22, 2006 6:36 pm

#88992 - ecurtz - Thu Jun 22, 2006 6:48 pm

#89005 - ikaris - Thu Jun 22, 2006 7:40 pm

#89009 - ikaris - Thu Jun 22, 2006 7:52 pm

#89016 - Mighty Max - Thu Jun 22, 2006 8:19 pm

#89024 - ikaris - Thu Jun 22, 2006 8:57 pm

#89033 - Sausage Boy - Thu Jun 22, 2006 9:18 pm

#89045 - Valmond - Thu Jun 22, 2006 9:35 pm

#89048 - Sausage Boy - Thu Jun 22, 2006 9:38 pm

#89049 - Valmond - Thu Jun 22, 2006 9:49 pm

#89050 - ikaris - Thu Jun 22, 2006 9:56 pm

#89054 - ikaris - Thu Jun 22, 2006 10:11 pm

#89055 - Mighty Max - Thu Jun 22, 2006 10:14 pm

#89056 - ikaris - Thu Jun 22, 2006 10:15 pm

#89059 - ikaris - Thu Jun 22, 2006 10:23 pm

#89072 - masscat - Thu Jun 22, 2006 11:38 pm

#89405 - ikaris - Sat Jun 24, 2006 6:58 pm

#89419 - Sausage Boy - Sat Jun 24, 2006 9:15 pm

#89425 - Mighty Max - Sat Jun 24, 2006 9:59 pm

#89433 - ikaris - Sat Jun 24, 2006 10:41 pm

#89434 - Mighty Max - Sat Jun 24, 2006 10:42 pm

#89435 - ikaris - Sat Jun 24, 2006 10:44 pm

#89437 - ikaris - Sat Jun 24, 2006 10:46 pm

#89438 - Mighty Max - Sat Jun 24, 2006 10:50 pm

#89452 - ikaris - Sat Jun 24, 2006 11:35 pm

#89460 - masscat - Sun Jun 25, 2006 12:27 am

#89480 - ikaris - Sun Jun 25, 2006 2:47 am

#89524 - Valmond - Sun Jun 25, 2006 9:56 am