padPortOpen failure

KaylaKaze · Post by **KaylaKaze** » Thu Dec 09, 2004 4:29 am

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.

Post by **pixel** » Thu Dec 09, 2004 5:07 am

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.

Post by **ooPo** » Thu Dec 09, 2004 6:05 am

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

KaylaKaze · Post by **KaylaKaze** » Wed Dec 29, 2004 2:58 pm

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 · Post by **KaylaKaze** » Sat Jan 01, 2005 4:32 pm

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.

Post by **Drakonite** » Sat Jan 01, 2005 9:11 pm

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)

Post by **pixel** » Sat Jan 01, 2005 11:47 pm

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

KaylaKaze · Post by **KaylaKaze** » Sun Jan 02, 2005 2:45 pm

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.

Post by **pixel** » Sun Jan 02, 2005 3:26 pm

Okay, so, alignment inside classes is broken. Thanks, that's what I wanted to know ;)

KaylaKaze · Post by **KaylaKaze** » Sun Jan 02, 2005 6:05 pm

oh! Is that what it is :-)

radad · Post by **radad** » Tue Jan 04, 2005 9:12 am

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 · Post by **rasmus** » Tue Jan 04, 2005 10:55 am

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 · Post by **radad** » Tue Jan 04, 2005 1:31 pm

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 · Post by **evilo** » Fri Jan 07, 2005 11:25 pm

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