gbadev.org forum archive

I've tried most things but I can't get this to work. Please someone tell me what I'm doing wrong.

This is what I want to do: Copy a palette array every frame with DMA, and then sync the frame. Here is my code:

Quote:

while (1)
{
// REG_BG0HOFS = (bg0_x++) >> 2;
// REG_BG3HOFS = (bg0_x++) >> 4;

DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);

while ((volatile u16) REG_VCOUNT != 160);
}

Now this code is so damn slow, I can't do anything else :(

I can make it go 100 times faster just by taking out the Vsync:

Quote:

while (1)
{
// REG_BG0HOFS = (bg0_x++) >> 2;
// REG_BG3HOFS = (bg0_x++) >> 4;

DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);

/////////// while ((volatile u16) REG_VCOUNT != 160);
}

What am I doing wrong here?

Here is my bat file that builds the game:

Quote:

path=c:\devkitadv\bin
gcc -o z.elf main.cpp
objcopy -O binary z.elf z.bin
pause

Please help!

put the load in the vblank interrupt.

Miked0801 wrote:

put the load in the vblank interrupt.

And how can I do that out from my code and compilator settings above?

Code:

while (1)
{
// REG_BG0HOFS = (bg0_x++) >> 2;
// REG_BG3HOFS = (bg0_x++) >> 4;
while ((volatile u16) REG_VCOUNT != 160);
DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);
}

why you want to copy the palette every cycle is beyond me though....

quick explaination of the code. there are 228 v lines drawn per frame,(only 160 are viewable) so we take advantage of the time lapse to draw the reminder 68 lines and do a dma.
[/code]
_________________
[Blog] [Portfolio]

yaustar wrote:

why you want to copy the palette every cycle is beyond me though....

But not beyond Google.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

yaustar wrote:

Code:

while (1)
{
// REG_BG0HOFS = (bg0_x++) >> 2;
// REG_BG3HOFS = (bg0_x++) >> 4;
while ((volatile u16) REG_VCOUNT != 160);
DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);
}

why you want to copy the palette every cycle is beyond me though....

quick explaination of the code. there are 228 v lines drawn per frame,(only 160 are viewable) so we take advantage of the time lapse to draw the reminder 68 lines and do a dma.
[/code]

I've already tried this. It doesn't matter where I put the DMA call in the game loop. It's too slow :(

Something must be wrong with the Vsync

tepples: ahh....interesting. I stand corrected.

edit:

Code:

while (1)
{
while ((volatile u16) REG_VCOUNT != 160){}
REG_DM3SAD = (u32)palette;//source of data
REG_DM3DAD = (u32)BGPaletteMem;//target for data
REG_DM3CNT = (128 | DMA_16NOW);//start copying NOW, in 16bit values
}

try this. if this works then there is something wrong with the function or the variables passed to it...
_________________
[Blog] [Portfolio]

If yaustar's version doesn't work, try modifying it with the following:

Code:

while (1)
{
while ((volatile u16) REG_VCOUNT != 160){}
REG_DM3SAD = (u32)palette;//source of data
REG_DM3DAD = (u32)BGPaletteMem;//target for data
REG_DM3CNT = (128 | DMA_16NOW);//start copying NOW, in 16bit values
while ((volatile u16) REG_VCOUNT == 160);
}

You could be running the DMA multiple times if it is completing before you advance to the next scanline.

Dan.

poslundc wrote:

If yaustar's version doesn't work, try modifying it with the following:

Code:

while (1)
{
while ((volatile u16) REG_VCOUNT != 160){}
REG_DM3SAD = (u32)palette;//source of data
REG_DM3DAD = (u32)BGPaletteMem;//target for data
REG_DM3CNT = (128 | DMA_16NOW);//start copying NOW, in 16bit values
while ((volatile u16) REG_VCOUNT == 160);
}

You could be running the DMA multiple times if it is completing before you advance to the next scanline.

Dan.

Both your and yaustar code don't work. It never copies the palette at all :(

This isn't just a problem for me when it comes to copying a palette array. I got the same problem with copying the OAM.

The DMA is not slow here, the Vsync is slowing the game loop down. If I take it out, the game will speed too fast.

Can it be something wrong with my GCC compiler?

Also I've tried to replace the DMA with memcpy, but it goes slower.

Is there anyone that got the same problem? I know you people are DMAing sprites all the time. Give me your source and I can try it.

Miked0801 wrote:

put the load in the vblank interrupt.

You would only do this if it happens every frame. Otherwise, you could use the flag in bits 12-13 of DMA3CNT_H to make the transfer wait until the next VBLANK to begin the transfer.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

Just a second...

It cannot possibly matter which order the DMA and vsync are in, when they are the only 2 things in a while(1) loop.

It also doesn't matter if the DMA is in the vblank interrupt, because doing the DMA right after the vsync is the same thing in almost all circumstances (except if the main loop takes longer than 1/60s).

If the DMA is running more than once per vblank, who cares? If it's so fast that it finishes in less than an hline, it won't be slowing the program down so horribly. (Of course you'd fix it in production code.)

Yaustar's code copied only 128 16-bit words, which is half as much as desired. Did it even copy that? If not, it's time to start asking about how things are #defined.

But perhaps the most important question is: Just how fast were you expecting it to go? Yes, if you remove the vsync it will run much faster. With the vsync it should run at 60Hz.

How fast is it running? If it runs at 60Hz, how much extra work can you do before it runs slower than 60Hz?

sajiimori wrote:

It cannot possibly matter which order the DMA and vsync are in, when they are the only 2 things in a while(1) loop.

It does, if the DMA is affecting VRAM.

Quote:

It also doesn't matter if the DMA is in the vblank interrupt, because doing the DMA right after the vsync is the same thing in almost all circumstances (except if the main loop takes longer than 1/60s).

If the DMA is in the vblank interrupt, then every time the interrupt fires the transfer will occur. What if you only want the DMA to transfer one time? for a splash screen for example...

However, as I re-read the OP, he did want it to occur every frame, so no harm done - my bad. ;)

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

Can yuo post the source for us to download because I want to why it doesnt seem to work.....it is driving me a little nutty here......
_________________
[Blog] [Portfolio]

jma wrote:

sajiimori wrote:

It cannot possibly matter which order the DMA and vsync are in, when they are the only 2 things in a while(1) loop.

It does, if the DMA is affecting VRAM.

Hmm...I'm having trouble thinking of how that can be. If the DMA occurs during vblank either way, what does it matter?

Even if the work takes longer than vblank (i.e. if the transfer is many times larger than a palette), that would cause the same problems whether its done in the interrupt handler or not.

sajiimori wrote:

Just a second...

It cannot possibly matter which order the DMA and vsync are in, when they are the only 2 things in a while(1) loop.

It also doesn't matter if the DMA is in the vblank interrupt, because doing the DMA right after the vsync is the same thing in almost all circumstances (except if the main loop takes longer than 1/60s).

If the DMA is running more than once per vblank, who cares? If it's so fast that it finishes in less than an hline, it won't be slowing the program down so horribly. (Of course you'd fix it in production code.)

Yaustar's code copied only 128 16-bit words, which is half as much as desired. Did it even copy that? If not, it's time to start asking about how things are #defined.

But perhaps the most important question is: Just how fast were you expecting it to go? Yes, if you remove the vsync it will run much faster. With the vsync it should run at 60Hz.

How fast is it running? If it runs at 60Hz, how much extra work can you do before it runs slower than 60Hz?

You will probably go WTF now :P

This is the exact same code, the difference is just that I took out the vsync from dma_slow.bin and renamed it dma_fast.bin

http://logotypes.se/tmp/dma_slow.bin

http://logotypes.se/tmp/dma_fast.bin

I just want to make it work. It's just a DMA in the main loop for god's sake ;_;

Sorry for double posting, but here's the source:

http://logotypes.se/tmp/dma_slow_source.zip

Please help me to find the problem. You will be my hero then ;_;

I agree with yaustar. Post the whole loop. I've been assuming that the code you've posted it the code you're compiling - is it? Or are you presenting pruned code? Other code there could be causing the problem. If there are a lot of cycles being used, it's possible to consistantly miss REG_VCOUNT == 160. This will cause the problems you were originally experiencing. In this case, removing the test will result in the palette transfers ripping away as you describe. If you can't get all of other cycles processed in a frame, maybe the following test might bring at least immediate relief:

while(REG_VCOUNT < 160){}
//do the DMA here

Just some perspective - I personally have blamed DKA for dozens of problems over a several year period. Without fail I have found that each problem was a bug in my own code.

while ((volatile u16) REG_VCOUNT < 160){}

After compiling your project with this change, I believe this is the effect you are looking for.

I dont 'quite' how it would miss 160 but doing > 160 is a lot better. Surprised that I missed that myself. I can Conifirm that this does work :)
_________________
[Blog] [Portfolio]

yaustar wrote:

I dont 'quite' how it would miss 160 but doing > 160 is a lot better.

I'm not certain myself. The DMA call is going to intermitantly happen right when hitting the 160th scan line (or rather right before) causing it to miss. Using !=160 jacked me up until I decided to instate the vbl irq instead. I only recently figured out that this approach would have worked fine for me as well.

sajiimori wrote:

jma wrote:

sajiimori wrote:

It cannot possibly matter which order the DMA and vsync are in, when they are the only 2 things in a while(1) loop.

It does, if the DMA is affecting VRAM.

Hmm...I'm having trouble thinking of how that can be. If the DMA occurs during vblank either way, what does it matter?

Because the DMA transfer returns immediately, it doesn't wait for it to complete before continuing the program. Of course, this is assuming assembly code -- I don't use HAM, so perhaps the HAM function does wait...

Think of this situation:

o Using a bitmapped mode, use DMA to copy a background each frame.
o At the bottom of the screen you will have a rectangle (health bar).

If you do this, most of the time the health bar will never be displayed (or be partially obscured), because the DMA starts, you draw the rectangle and then the DMA finishes (covering it up).

Of course, you can write a routine to wait for the DMA to complete, by constantly checking the DMA_ENABLE bit in the proper CNT register and wait for it to be reset.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

yaustar wrote:

I dont 'quite' how it would miss 160 but doing > 160 is a lot better. Surprised that I missed that myself. I can Conifirm that this does work :)

But I don't want it to look like this:
[Images not permitted - Click here to view it]

Is there just me who get this vierd effect while using this code in the main game loop?:

Quote:

while (1)
{
REG_BG0HOFS = (bg0_x++) >> 1;
REG_BG3HOFS = (bg0_x++) >> 2;

DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);

// Just comment this line out to make it 1000 times faster:
while ((volatile u16) REG_VCOUNT > 160){}
}

Quote:

Because the DMA transfer returns immediately, it doesn't wait for it to complete before continuing the program.

Actually, I don't think that's true.

GBATEK:

Quote:

The CPU is paused when DMA transfers are active, however, the CPU is operating during the periods when Sound/Blanking DMA transfers are paused.

Hey, what do ya know. He wasn't posting the code he was actually using after all.

Code:

REG_BG0HOFS = (bg0_x++) >> 6;
REG_BG3HOFS = (bg0_x++) >> 8;

Do you realize that this will only move the foreground one pixel every 64 frames (x >> 6 == x / 64), which is less than a pixel a second?

BTW, you should be using while(REG_VCOUNT!=160). That is, until you get the hang of interrupts and you start using swi 5.

sajiimori wrote:

Quote:

Because the DMA transfer returns immediately, it doesn't wait for it to complete before continuing the program.

Actually, I don't think that's true.

Try it.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

sajiimori wrote:

Hey, what do ya know. He wasn't posting the code he was actually using after all.

Code:

REG_BG0HOFS = (bg0_x++) >> 6;
REG_BG3HOFS = (bg0_x++) >> 8;

Do you realize that this will only move the foreground one pixel every 64 frames (x >> 6 == x / 64), which is less than a pixel a second?

BTW, you should be using while(REG_VCOUNT!=160). That is, until you get the hang of interrupts and you start using swi 5.

I don't care what I'm doing right now. I want to fix the vsync/DMA problem.

Here is the source code:

http://logotypes.se/tmp/dma_slow_source.zip

Someone, do whatever you like, just fix the problem please.

you should, since it is slowing the entire thing down....
edit: incorrect wording, It is running at the right speed which is very very slowly....

try this for example

Code:

while (1)
{
   REG_BG0HOFS = (bg0_x++);// >> 6;
   //REG_BG3HOFS = (bg0_x++) >> 8;

   // Just comment this line out to make it 1000 times faster:
   while ((volatile u16) REG_VCOUNT != 160){}

   DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);
}

_________________
[Blog] [Portfolio]

Last edited by yaustar on Thu Jan 08, 2004 8:47 pm; edited 1 time in total

LOst?,

Oh sorry, I thought the problem was the speed. It works fine for me when I change it to move the background faster. What is the problem again?

jma,

Is this an adequate test? The screen gets filled very very slowly, presumably because the DMA is blocking the CPU.

Code:

#include "gba.h"

#define DMACPY32(dst,src,len) \
REG_DM3SAD = (int)(src); \
REG_DM3DAD = (int)(dst); \
REG_DM3CNT = (len) | DMA_ENABLE | DMA_TIMING_IMMEDIATE | DMA_32

main()
{
u16* p = VIDEO_MEMORY;
REG_DISPCNT = MODE_3 | BG2_ENABLE;

while(1)
{
DMACPY32((u8*)EXTERNAL_RAM+1,
EXTERNAL_RAM,
256000);

*p++ = 0x1f;
}
}

yaustar wrote:

you should, since it is slowing the entire thing down....
edit: incorrect wording, It is running at the right speed which is very very slowly....

try this for example

Code:

while (1)
{
   REG_BG0HOFS = (bg0_x++);// >> 6;
   //REG_BG3HOFS = (bg0_x++) >> 8;

   // Just comment this line out to make it 1000 times faster:
   while ((volatile u16) REG_VCOUNT != 160){}

   DMA_Copy (3, (void*) BGPaletteMem, (void*) palette, 256/2, DMA_32NOW);
}

So what you're saying is that I should live with the slowdown. It's part of GBA, right? The Gameboy Advance is too slow to copy a 256 word array, so better start programming for the PC instead, or maybe N-gage can copy 512 bytes faster?

What if I want to copy a sprite into the OAM? No, that's inpossible for the Gameboy Advance to do, because a sprite is bigger than the palette.

I will not stay much longer here if this is the answer. I want to program games, and if Gameboy Advance is so slow, than I will head back to the old consoles from 1990, they can copy a little palette aray faster.

Thank you :\

no, I am telling you that the code says to go that fast. The GBA is fine with doing a lot more then this (as I found out when doing a radar). The scrolling speed of the background is going as fast as you set it to go.... I told it to go one pixel per frame and it did that at the right speed.

you are telling to go 1 pixel every 2(power of 6) or 2(power of 8) frames which is 64 and 256 frames respectively (1 sec and 4 sec) which is very slow.

[quote="sajiimori"]

Code:

REG_BG0HOFS = (bg0_x++) >> 6;
REG_BG3HOFS = (bg0_x++) >> 8;

Do you realize that this will only move the foreground one pixel every 64 frames (x >> 6 == x / 64), which is less than a pixel a second?
_________________
[Blog] [Portfolio]

Last edited by yaustar on Thu Jan 08, 2004 9:47 pm; edited 1 time in total

yaustar wrote:

no, I am telling you that the code says to go that fast. The GBA is fine with doing a lot more then this (as I found out when doing a radar). The scrolling speed of the background is going as fast as you set it to go.... I told it to go one pixel per frame and it did that at the right speed.

you are telling to go 1 pixel every 2(power of 6) or 2(power of 8) frames which is 64 and 256 frames respectively (1 sec and 4 sec) which is very slow.

Upload the ROM and let me see O.o;;

[quote="yaustar"]

yaustar wrote:

no, I am telling you that the code says to go that fast. The GBA is fine with doing a lot more then this (as I found out when doing a radar). The scrolling speed of the background is going as fast as you set it to go.... I told it to go one pixel per frame and it did that at the right speed.

you are telling to go 1 pixel every 2(power of 6) or 2(power of 8) frames which is 64 and 256 frames respectively (1 sec and 4 sec) which is very slow.

sajiimori wrote:

Code:

REG_BG0HOFS = (bg0_x++) >> 6;
REG_BG3HOFS = (bg0_x++) >> 8;

Do you realize that this will only move the foreground one pixel every 64 frames (x >> 6 == x / 64), which is less than a pixel a second?

I can't do anything more bacause of the slowdown. Therefore I start to think that something is wrong with my compiler. The only way to see if my compiler is wrong, is to see your compiled ROM

Please upload

Copy and paste that code that I wrote and you should see for yourself the difference..

edit: this it running at 1 pixel per frame
http://madsims.net/~yaustarc/misc/z.zip
_________________
[Blog] [Portfolio]

So, if that's the correct way of doing the palette DMA copy and moving the background, then this is the final result:

http://logotypes.se/tmp/fade.bin

I still dont understand why you are coping the palette every loop though.....I look at in a sec after I stop rendering my animation

edit: now i see..it may be easier to use the register REG_BLD_MOD to do fade to black and white though
_________________
[Blog] [Portfolio]

sajiimori wrote:

jma,

Is this an adequate test?

Code:

DMACPY32((u8*)EXTERNAL_RAM+1,
EXTERNAL_RAM,
256000);

Sajiimori,

Yes and no :) -- Yes, because this is much like what the OP had in mind. No for me, because your destination address is not VRAM.

Both will show 2 things: the DMA is blocking the CPU and that it runs asyncronously. Meaning that you either want to wait for the DMA to finish or at the very least not write to the same location.

Edit: that may sound contradictory... what I mean by 'blocking' is that the DMA is slowing down the CPU, not halting it.

To the OP (Lost?):

Do not use the DMA to transfer sprite data to OAM or palette data. It is a small amount of data and is faster to code a very tight loop (IMHO) if your source data is in IWRAM. Sample using THUMB:

Code:

mov R0,#0x20 ; 512 bytes
mov R1,#5
lsl R1,R1,#24 ; R1 = bg palette dest
ldr R2,=source_address
copy_sprite_data:
ldmia R2!,{r3-r6}
stmia R1!,{r3-r6}
sub r0,#1 ; 16 bytes per iteration
bgt copy_sprite_data

Using a C loop should be almost as fast. In Dragon BASIC, this is what I do and it is very quick.

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

jma: you say that palette/sprite data is too small amount of data to be used by DMA (effectively). What would you considered a reasonable/large amount of data?
_________________
[Blog] [Portfolio]

jma wrote:

Do not use the DMA to transfer sprite data to OAM or palette data. It is a small amount of data and is faster to code a very tight loop (IMHO) if your source data is in IWRAM.

The ldmia/stmia copy does not run faster than DMA because unlike DMA, a CPU copy still needs to repeatedly read the instructions in the loop. The only time a 'stmia' loop runs faster than DMA is in an unrolled memset() type loop because DMA needs to reread the source location.

Setup time on DMA isn't so bad either: three 32-bit loads (src, dst, count/control) and a 'stmia' to the DMA3 register base.

Bottom line: DMA is faster for copying. 'Stmia' is faster for clearing.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

yaustar wrote:

jma: you say that palette/sprite data is too small amount of data to be used by DMA (effectively). What would you considered a reasonable/large amount of data?

256 words of data isn't much. Even Microsoft Windows' GDI can handle more palette entries faster than GBA's DMA

huh?

Jma was soaying that small chunks of data shouldnt be used be dma but normal c loops. I was asking what 'would' be a large chunk of data to say 'oh this should use the DMA insted.'
_________________
[Blog] [Portfolio]

My cut-off (in C Code) is around 32 bytes - though that probably is a bit high. I just do an assign of a structure to get the compiler to use ldmia/stdmia correctly:

typedef struct _FOO32
{
u32 word1;
u32 word2;
u32 word3;
u32 word4;
} FOO32;

FOO32 first, second;

first = second;

and that will do a 16-byte copy for you in C code as efficiently as the thumb system will allow.

Mike

jma,

Why does this code draw zero pixels, regardless of the source/destination/size? If the transfer merely slows the processor, shouldn't at least a few pixels get drawn?

Maybe it's time you present some evidence for your argument that DMA transfers do not fully block the CPU -- especially considering that you are contradicting conventional GBA wisdom (i.e. GBATEK). =)

Code:

main()
{
u16* p = VIDEO_MEMORY;
REG_DISPCNT = MODE_3 | BG2_ENABLE;

DMACPY32((u8*)EXTERNAL_RAM+1,
EXTERNAL_RAM,
256000/4);

while(REG_DM3CNT & DMA_ENABLE)
*p++ = 0x1f;

while(1);
}

This was just my experience when coding a ROM. At the time I was only using an emulator and not actual hardware, though, so perhaps the emulator (VBA) was wrong.

When I get home I'll try making something to test it and see what happens... If I am wrong, I'll be first in line to admit it, though :)

Jeff
_________________
massung@gmail.com
http://www.retrobyte.org

gbadev.org forum archive

C/C++ > Can someone help me (DMA/VSYNC slowdown)

#14467 - LOst? - Wed Jan 07, 2004 5:03 am

#14469 - Miked0801 - Wed Jan 07, 2004 5:18 am

#14470 - LOst? - Wed Jan 07, 2004 5:21 am

#14474 - yaustar - Wed Jan 07, 2004 5:39 am

#14475 - tepples - Wed Jan 07, 2004 5:43 am

#14480 - LOst? - Wed Jan 07, 2004 7:17 am

#14483 - yaustar - Wed Jan 07, 2004 8:44 am

#14496 - poslundc - Wed Jan 07, 2004 4:57 pm

#14500 - LOst? - Wed Jan 07, 2004 5:47 pm

#14514 - jma - Wed Jan 07, 2004 9:44 pm

#14519 - sajiimori - Wed Jan 07, 2004 11:17 pm

#14528 - jma - Thu Jan 08, 2004 1:16 am

#14531 - yaustar - Thu Jan 08, 2004 1:52 am

#14533 - sajiimori - Thu Jan 08, 2004 1:58 am

#14540 - LOst? - Thu Jan 08, 2004 4:26 am

#14542 - LOst? - Thu Jan 08, 2004 4:35 am

#14545 - johnny_north - Thu Jan 08, 2004 5:01 am

#14546 - johnny_north - Thu Jan 08, 2004 5:17 am

#14549 - yaustar - Thu Jan 08, 2004 8:11 am

#14554 - johnny_north - Thu Jan 08, 2004 3:20 pm

#14559 - jma - Thu Jan 08, 2004 5:53 pm

#14562 - LOst? - Thu Jan 08, 2004 7:48 pm

#14565 - sajiimori - Thu Jan 08, 2004 8:05 pm

#14567 - sajiimori - Thu Jan 08, 2004 8:20 pm

#14569 - jma - Thu Jan 08, 2004 8:23 pm

#14571 - LOst? - Thu Jan 08, 2004 8:26 pm

#14574 - yaustar - Thu Jan 08, 2004 8:43 pm

#14575 - sajiimori - Thu Jan 08, 2004 8:45 pm

#14576 - LOst? - Thu Jan 08, 2004 9:23 pm

#14577 - yaustar - Thu Jan 08, 2004 9:39 pm

#14578 - LOst? - Thu Jan 08, 2004 9:43 pm

#14580 - LOst? - Thu Jan 08, 2004 9:51 pm

#14581 - yaustar - Thu Jan 08, 2004 9:52 pm

#14582 - LOst? - Thu Jan 08, 2004 10:08 pm

#14583 - yaustar - Thu Jan 08, 2004 10:11 pm

#14584 - jma - Thu Jan 08, 2004 10:20 pm

#14586 - yaustar - Thu Jan 08, 2004 10:53 pm

#14587 - tepples - Thu Jan 08, 2004 10:59 pm

#14590 - LOst? - Fri Jan 09, 2004 1:14 am

#14593 - yaustar - Fri Jan 09, 2004 1:45 am

#14603 - Miked0801 - Fri Jan 09, 2004 3:38 am

#14606 - sajiimori - Fri Jan 09, 2004 7:05 am

#14617 - jma - Fri Jan 09, 2004 6:57 pm