PDX has been nice enough to share hints with us on how they found this "exploit" and yet everyone keeps beating around the bush and looking for other ways to produce the same thing. Why don't we start discussing the information they shared in the nfos and expand on it.
For Example: We suggest why not have a look in multiple SPEs? Since they use shared memory for tasks! couldn't there be a bug in that part? and what about LS size limitation? Enough for now!
and a quick scan through the BE Handbook brings this to my attention:
The SPU fetches instructions from its unified (instructions and data) 256-KB local store (LS), and it loads and stores data between its LS and its single register file for all data types, which has 128 registers, each 128 bits wide. The SPU has four execution units, a DMA interface, and a channel interface for communicating with its MFC, the PPE and other devices (including other SPEs). Each SPU is an independent processor element with its own program counter, optimized to run SPU programs. The SPU fills its LS by requesting DMA transfers from its MFC, which implements the DMA transfers using its DMA controller. Then, the SPU fetches and executes instructions from its LS, and it loads and stores data to and from its LS.
And: The Local Store (LS) is a 256-KB, ECC-protected, single-ported, noncaching memory. It stores all instructions and data used by the SPU. It supports one access per cycle from either SPE software or DMA transfers. SPU instruction prefetches are 128 bytes per cycle. SPU data-access bandwidth is 16 bytes per cycle, quadword aligned. DMA-access bandwidth is 128 bytes per cycle. DMA transfers perform a read-modify-write of LS for writes less than a quadword.
Rather then complaining and waiting for an ISO loader why doesn't everyone do something about it. Even if your not a programmer you can research and gather information, then when someone stops in a reads this stuff they might think of something and with our help find a hole.
I approved this thread, however, I renamed it so that lamers (kids) don't start posting "begging/ranting" junk here.
PS3 DEVs who wish to discuss and elaborate on these hints/points may do so here, and I will add to them as the need arises... I do have some new info to share of my own on how the PDX iSO Loader actually works. If the conversation moves in the right direction I may do so soon as it's applicable.
A blind helping another blind (better than no help at all?)
I will comment on this subject and give advice (not that I'm any more knowledgeable than anyone else here (I still don't have anything working)) when I wake up. Will post links to obtain the Cell BE SDK's legally if it's alright with site, as well as links to how to code particularly to the SPU's LS through the OtherOS area. Not sure it's helpful, but only time will tell. Back in 10 hours.
Wow, 300 posts. I have no life.
Do you feel that the information that is being shared is pointing in the right direction? Any additional details that may point others in the right direction will help reduce waste cycles.
Honestly, I think some people may be surprised on how theirs works actually... it clears up (makes sense out of) a few of their mystic NFO files, and the first part is in a different direction but considerably easier. The info above is likely to be more useful for the second part, so it's definitely not wasted effort. I am not trying pull a "PDX" talking in riddles, mainly I'd just like to see some more collaboration/useful replies here before I start spilling new (but specific) info out.
Thus far we have 2-3 people who shared random links, but not much solid DEV discussion. My job as an Admin (who is also a Forum Moderator) is to lead the direction of the discussion... and when it actually starts getting indepth I will be happy to elaborate where I can.
its's cool that you guys post all the info we can get about SPE/PPU. We can get something from that. But what i've been seeing so far on the docs (maybe i have missed something) is how the SPE/PPU works and how processes are created/destroyed, and SDK. We need more than that... we need stuff about the hypervisor (it controls alot of stuff) and ideas on how to get some code running along with the GameOS or a real game...