confusing problem with setup

[Hedonis]

Heya's, Ive got a problem and hopefully you guys will be able to point me in the right direction.

Basically I spent the past few days finally trying to get my development setup running which included grabbing the ps2sdk from the cvs and compiling it and then the latest gskit from the website.

After compiling gskit I thought i'd start playing with the texture example and thats when I hit a snag... using texture.elf via inlink I noticed it would fail with:

open name host:bitmap.raw flag 1 data 41378
open fd = 2
[NET] : Sent bitmap.raw at 190KB/s
Texture 1 Height: 256
Texture 1 Width: 256
open name host:bsdgirl.bmp flag 1 data 41378
open fd = -1
Could not load bitmap: host:bsdgirl.bmp


So I have a look at the texture.c and nothing really stands out so I modify the example so that it only does one texture with

gsKit_texture_bmp(gsGlobal, &Tex2, "host:bsdgirl.bmp");

now, I get

open name host:bsdgirl.bmp flag 1 data 41378
open fd = 2
Get Reboot Request From EE

After playing around gstexture source I came to the conclusion that the offending line in gsKit_texture_bmp was:

FTexSize = fioLseek(File, 0, SEEK_END);

which was returning -1 when it should be working fine. My only solution was to move it to the top of the function when the file is first opened. Once that was done, my example would at least show a black box where the bmp should be and not crash out.

Finally I try to load the texture example using the above mod to gstexture.c and it still fails with


open name host:bsdgirl.bmp flag 1 data 41378
open fd = 2
Texture 2 Height: 384
Texture 2 Width: 256
open name host:bitmap.raw flag 1 data 41378
open fd = -1
Could not load texture: host:bitmap.raw

and right about now im frustrated, is this a problem with my fileio compile, is it something I dont see in gskit or is it inlink not sending the 2nd file etc.


Im sorry if this hasnt made sense to anyone but im at a total loss
Hed

[Drakonite]

Inlink has a lot of bugs. I'd really suggest you try a different loader before you claim there are any bugs with the code.

[ooPo]

Give this client a try:

http://www.oopo.net/consoledev/files/ps2client.exe

Use it as:

ps2client -h 192.168.0.10 execee host:program.elf

[Hedonis]

You were absolutely right guys, seems inlink was the issue!

thanks
Hed

[Hedonis]

Sorry got another question, started playing around with gskit and wanted to try and load a couple of textures which are 256x256 but im finding that gsKit_vram_alloc is failing as the the current pointer in the buffer is going past a magic number 4194304

if(gsGlobal->CurrentPointer >= 4194304)

so the output I get is

Input ELF format filename = host:main.elf
0 00100000 0002c020 ...
Loaded, host:main.elf
start address 0x100008
gp address 00000000
CP: 00000000, size: 00168000
CP: 00168000, size: 00168000
CP: 002D0000, size: 000B4000
open name host:Image/test.bmp flag 1 data 41378
open fd = 2
CP: 00384000, size: 00040000
open name host:Image/test.bmp flag 1 data 41378
open fd = 2
CP: 003C4000, size: 00040000
ERROR: Not enough VRAM for this allocation!
VRAM Allocation Failed. Will not upload texture.

Is there 'rules' to how much/size etc that can be stored in the buffer and does anyone have a suggestion as to how I could then display a full screen texture?

Hed

[boomint]

if(gsGlobal->CurrentPointer >= 4194304)

is 4mb vram limit :)

[Hedonis]

yup that makes sense but even if I have enough space left in vram it still seems to stuff up on large textures and I cant see why.

I'll stuff around with it tomorrow, I need sleep
Hed

[ooPo]

I don't know if gsKit works around it but there's a limit to the size you can transfer to vram in one go. It is a limitation of the GIFTAG used to specify the transfer itself - I believe you can only send 512k at a time.

The easiest way around it is to split up your transfer into two pieces. Remember to split on a page boundary or you'll get garbage.

[Hedonis]

It looks as if it should but after doing a bit of reading up through tutorials etc I think I can see a problem. In the part of upload code which sets up the Image data transfer

Code: Select all

while (packets-- > 0) {
	        *p_data++ = DMA_TAG( DMA_MAX_SIZE, 1, DMA_REF, 0, (u32)p_mem, 0 );
	        *p_data++ = 0;
		p_mem+= (DMA_MAX_SIZE * 16);
		test++;
	}
	if (remain > 0) {
	        *p_data++ = DMA_TAG( remain, 1, DMA_REF, 0, (u32)p_mem, 0 );
	        *p_data++ = 0;
			test++;
	}

DMA_MAX_SIZE is defined as xFFFF which is the entire vram size rather than the limit that you've mentioned ooPo (16384 qwords). Changing it appears to only partially work as it seems to ignore the 'remainder' qwords. I'll keep reading and trying to compare it with how others do it but at least its helping me get my head around it all.

Hed