forums.ps2dev.org

KaylaKaze · Joined: 05 May 2004 Posts: 75 Location: NC, USA

Assuming padInit() is successful, what could cause padPortOpen(0,0, padBuf) to fail? If I put my call to my pad initialization function early, it works, but if I put it later, like after the graphics have been initialize, it fails.

pixel · Joined: 30 Jan 2004 Posts: 791

I had the same issue... I assumed it was due to some dma problem between gsKit and the libpad, but, no idea...

Well, I'm not the best one to answer that.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

ooPo · Posted: Thu Dec 09, 2004 6:05 am Post subject:

It may be tied to the pads using the vsync interrupt to update the controller information. Perhaps your graphics initialization code is broken.

KaylaKaze · Joined: 05 May 2004 Posts: 75 Location: NC, USA

Assuming this is a graphics something issue, how would I fix it? I switched my code from libIto to gsLib and still have the problem. I put the pad initialization routines before the graphics initialization and still have the problem. I completely removed the graphics manipulation code and still have the problem. I added VSync waits before every pad command and still have the problem. Please! It's driving me nuts! It's making me almost break down in tears! The fact that nothing specific seems to cause it to go from working to not working makes it even worse.

KaylaKaze · Joined: 05 May 2004 Posts: 75 Location: NC, USA

I think I figured it out so keep this post for future reference :-)

the padPortOpen's third parameter needs to be in section .bss. Since this may not always happen by accident, the padBuf needs __attribute__ ((section (".bss"))) on it, especially when dealing with classes. Since __attribute__ ((section (".bss"))) can't be used in the class definition, it may be best (or necessary) to make your padBuf a global. Anyway, I think that's the solution. After I did that, my code worked perfectly, and would explain why changing an unrelated variable would make it act weird.

Drakonite · Site Admin Joined: 17 Jan 2004 Posts: 989

Um... I think the issue is actually alignment, and putting it in bss just happens to make it align correctly. This would also explain why changing some unrelated variable would make it act weird (adding/removing a variable could end up altering at what alignment other variables end up)
_________________
Shoot Pixels Not People!
Makeshift Development

pixel · Joined: 30 Jan 2004 Posts: 791

Right. Try with a __attribute__ ((aligned(64))); on a global (non bss) variable first, then in the class. I don't know if the attribute may work in a member of a class though. Just try it and report back :)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

KaylaKaze · Joined: 05 May 2004 Posts: 75 Location: NC, USA

I would agree, but it was 64 aligned the whole time. I'm not that dense :-) It could have been only because it was in a class and not global. But 64 aligned in a class didn't work all the time. Considering how it's not an issue that happens all the time, it'd be hard to figure out exactly which one is the problem.

pixel · Joined: 30 Jan 2004 Posts: 791

Okay, so, alignment inside classes is broken. Thanks, that's what I wanted to know ;)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

KaylaKaze · Joined: 05 May 2004 Posts: 75 Location: NC, USA

oh! Is that what it is :-)

radad · Posted: Tue Jan 04, 2005 9:12 am Post subject:

I also tried it aligned as a local variable and that failed also. Is it the alignment that is failing or are there other requirements for the address?

rasmus · Joined: 21 Jul 2004 Posts: 17 Location: G�teborg, Sweden

This sounds very much like the stack is unaligned, or rather not aligned strictly enough.

A non-static local variable as well as a member variable in a local object are allocated by reserving space on the stack. If the stack for example is guaranteed to be 8 byte aligned then there is only a 1-in-8 chance that the 64 byte aligned variable will get the correct alignment.

radad · Posted: Tue Jan 04, 2005 1:31 pm Post subject:

Has anyone tried using the memalign function from malloc.h to allocate memory on a 64 byte boundary?

And if this does work wouldn't be better if the padPortOpen function used it internally rather than requiring the user to supply this arbritary lump of memory?

evilo · Joined: 22 Apr 2004 Posts: 230

I used the memalign function to allocate my pad buffer (that is a member of a class, so c++) :

padBuf = (char *)memalign(64, 256);

weird thing is that the the code hangs up on the padInit(0) call ....

it's the first time I see that ... (padinit() call that fails...
Since this is is not my code, I don't want to completely rewrite it, and then removing the object stuff for the pad only would be a big mess .... but if anyone has a clue on this .. !