knowing that sceGpioSet(0x80) will turn on the WLAN led and sceGpioSet(0x40) will turn on the MS one
and that sceGpioClear(0x80) will turn wlan led off and with arg 0x40 the ms led..
so.. portSet will set the value passed as an argument at address 0xBE240008
but if i do something like
sceGpioSet(0x80)
sceGpioSet(0x40)
both leds are on, BUT the value at 0xBE240008 is overwritten
then another thing that i cannot understand is why in the three functions the addresses are different...
They use separate addresses because it's hardware. Writing to one address will cause the set bits to be set in the hardware. They will stay set until you write to the other address, where set bits will clear that bit in the hardware. It's pretty common in various things. You could combine the LED and MS by writing 0xC0, which is just both bits 0x80 and 0x40. Anywho, it's pretty common to put a sync after writing to hardware - it makes sure the hardware bus transfer is done before continuing.
ok, i understand thank you!.
but from now on, things can be discovered only by testing, is no more possible to "reverse" i mean, to discover the 0x80 an 0x40 values i can only look (for example) at led.prx, but not "inside" gpio..
am i right?
and since i'm writing, where can i get more info on gpio?, what is it in psp hardware? is it a chip? is it like syscon?
phobox wrote:ok, i understand thank you!.
but from now on, things can be discovered only by testing, is no more possible to "reverse" i mean, to discover the 0x80 an 0x40 values i can only look (for example) at led.prx, but not "inside" gpio..
am i right?
and since i'm writing, where can i get more info on gpio?, what is it in psp hardware? is it a chip? is it like syscon?
thanks
Once you hit the hardware, you either need to know more functions like the one to set the power or ms leds, or you just have to poke the hardware with different values and see what happens. The latter can sometimes get you in trouble if the values do something bad, so it's better to RE functions if you have them.
GPIO means General Purpose Input/Output. It's a register in the hardware that simply buffers lines that do things, like control the LEDs or connect to switches or similar hardware related things. I seem to remember old threads with some info on the GPIO - you might try searching the old threads.
knowing that sceGpioSet(0x80) will turn on the WLAN led and sceGpioSet(0x40) will turn on the MS one
and that sceGpioClear(0x80) will turn wlan led off and with arg 0x40 the ms led..
so.. portSet will set the value passed as an argument at address 0xBE240008
but if i do something like
sceGpioSet(0x80)
sceGpioSet(0x40)
both leds are on, BUT the value at 0xBE240008 is overwritten
then another thing that i cannot understand is why in the three functions the addresses are different...
and what about the "sync"?
thanks
the "int argX" stands for the number of arguments for that function. Its runs differently than what you might think.
Why are you posting a non-answer to a question I already answered? Try reading the thread to see if there are still questions before posting, especially when your post doesn't give any extra info.
ok in this one are wiriiten strange things...
eg
sceGpioPortSet(0x00000003);
is
_sw(0xBE240008, _lw(0xBE240008) | 0x00000003);
and another one
sceGpioPortClear(0x00000003);
is
_sw(0xBE240008, _lw(0xBE240008) | 0x00000003);
now there are two things to consider: i did't understand that that code is right (but i don't think so) OR that info is incorrect or old.
-----------
by my self ( a bit of testing) i figured out that if I call
sceGpioPortSet(0x80)
to turn the wlan led on, the value returned with
sceGpioPortRead(); is the default value + 0x80.
the default value is 0x07000027.
if i do (for example)
sceGpioPortSet(0x80)
sceGpioPortSet(0x40)
sceGpioPortRead() will return 0x070000E7, that is 0x07000027 + 0x80 + 0x40
in other words, portSet will add the arg value to the gpio and portClear will subtract it....
EDIT: another thing, if I simply call sceGpioPortSet(led) the led will simply flash and then it turns off, to keep it on you need to keep calling that function.
don't know why this....
Yeah, there probably are some problems with some of that old hardware info... remember that most of that stuff is only slightly researched - there wasn't much need for that for the majority of homebrew.
The LED flashing is probably due to a system function setting the LEDs to what it thinks they are supposed to be periodically. You'd have to find where it stores its copy of what to set the GPIO to, or hook that function to make the LEDs not flash. Again, that's something that really hasn't been looked into much.