dont mean to be a punk, but. is there anyway to boot homebrew on latest version of firmware ? (keep in mind i already know that you can with otheros+old-firmware ).
if not, homebrew on ps3 seem hopeless unless someone find a way to decrypt hdd data. or something like a exploit.
just picked up a new ps3 an found out they remove card slot and only 2 usb port. now im going to have to plug in a card reader and a hub, that going to rip out those **** usb port on it.
now sony is keeping homebrew out because of stuppid things like hdloader from the past.
o well, back to ps2 dev for now
boot homebrew another way.
What the hell are you talking about? As far as I know other-os still works on the latest firmwares. And sure the card slots are gone but that is why you create an other-os partition, stick on a boot loader (a one time use of a usb key or card reader) and I think that even will load your code over the network if you so desire.
Re: sorry
Demo 1.1 hasn't worked since the firmware passed 2.1. Guess you missed that. :) It would be nice if Sony just showed the proper way to use the hypervisor to access the RSX. It's not like it would suddenly cause "piracy" or even a sudden decrease in people buying PS3 games.LionX wrote:o, sorry. i tried otheros demo 1.1 which uses the RSX. i just tried 1.0 and it boots on latest firmware.
so there is a way to boot, just no 3d calc/rsx
Maybe other reasons exist :
- Sony may fear Nvidia lawyers if they give access to something they didn't pay Nvidia for (RSX programming available to large public)
- A way to access memory from some undocumented opcode executed in shader
that would bypass hypervisor, may exist... (not sure about that one, and I have no time to verify it at the moment...)
- Sony may fear Nvidia lawyers if they give access to something they didn't pay Nvidia for (RSX programming available to large public)
- A way to access memory from some undocumented opcode executed in shader
that would bypass hypervisor, may exist... (not sure about that one, and I have no time to verify it at the moment...)
Sony wouldn't have to say how to program it - everyone already knows. The only thing they need is how to ACCESS it.ps2devman wrote:Maybe other reasons exist :
- Sony may fear Nvidia lawyers if they give access to something they didn't pay Nvidia for (RSX programming available to large public)
- A way to access memory from some undocumented opcode executed in shader
that would bypass hypervisor, may exist... (not sure about that one, and I have no time to verify it at the moment...)
More likely, it's just in-fighting between the part of Sony that wants linux and the part that wants to root kit your PC. You'll notice that NOTHING is actually explained. The only info there is comes from the linux source code... and Sony won't even discuss THOSE parts despite being open source.
I think people would settle for a closed-source linux driver from nVidia - like the regular nVidia drivers.
I am sorry but the likelyhood that any decent games would come out for the linux side of things is small to minimal, and due to the shit poor processor in the thing (and the general laziness of most "porters") then you would be far better off spending the $400 on a cheapo PC than using a PS3 if you just wanted to play emulators.
I still subscribe to the large gaping security hole theory tbh :)
I still subscribe to the large gaping security hole theory tbh :)
While there are a few good games in linux that NEED hardware OpenGL (Neverball, Scorch3D, ioquake3... ), this probably doesn't even show a weak correlation to loss in games sales. Not many people use linux in the first place. I'd be shocked if you could find even a handful of people who would not buy PS3 games if the OtherOS had a video driver. Having hardware OpenGL on my PC for linux has never stopped me from buying a PC game, so why do people think that's what would happen on the PS3?!?jonwil wrote:More than likely, they don't want anyone writing 3D games on the OtherOS since everyone who uses the OtherOS for gaming is one less person who buys proper PS3 games that earn Sony money (remember that the PS3 is sold at a loss and the profits come from the sales of games and blu-ray movies)
@TyRaNiD - if it were a security hole, Sony would have just fixed it and allowed a binary driver. Sony is certainly quick about fixing holes found in the PSP. No, there's some other reason...
I somehow wonder why everyone 'needs' RSX access. If you want to make some 3d games, you can write your software rasterizer using SPUs (no, it's no rocked science). I somehow doubt that this limitation is the reason nobody does a ps3-linux game, really!
I mean, the RSX is nothing revolutionary, you won't do any extreemly funky stuff that you can't do on pc. And games like quake were running in software on damn slow CPUs (compared to cell).
With the amount of memory and cpu power (and harddisk), I'm sure you can get games running that look superior to PS2 games. And even without extreem realistic shader effects, those game can be fun just like PS2 games were/are.
I dont want to bash you guys, but I feel like there would be always bashing against sony. We have now from beginning on programming access to the console, just like we always wished for PS2 PSX etc. further we have even linux running on it, with all tools and libs (beside RSX). I dont see any homebrew game that got to it's limit on PS3 and would need RSX access.
am I the only one with that opinion?
rapso
I mean, the RSX is nothing revolutionary, you won't do any extreemly funky stuff that you can't do on pc. And games like quake were running in software on damn slow CPUs (compared to cell).
With the amount of memory and cpu power (and harddisk), I'm sure you can get games running that look superior to PS2 games. And even without extreem realistic shader effects, those game can be fun just like PS2 games were/are.
I dont want to bash you guys, but I feel like there would be always bashing against sony. We have now from beginning on programming access to the console, just like we always wished for PS2 PSX etc. further we have even linux running on it, with all tools and libs (beside RSX). I dont see any homebrew game that got to it's limit on PS3 and would need RSX access.
am I the only one with that opinion?
rapso
J.F. wrote:If you can run a binary driver you can run a free driver, and to be able run the binary driver you have to "open" the RSX which probably make the sequrity hole(s) possible to exploit. That is my guess/analysis anyway...jonwil wrote:
@TyRaNiD - if it were a security hole, Sony would have just fixed it and allowed a binary driver. Sony is certainly quick about fixing holes found in the PSP. No, there's some other reason...
No, alot of people in this community are thinking like this, however not much is being done.rapso wrote:am I the only one with that opinion?
I think another factor is that PS2/PSP/DS/etc dev are all based on the result of reversing engineering libraries. The PS3 however requires actually designing systems from scratch which I think people are finding more challenging than expected (especially on such a complex system).
There are a couple of different groups that have been working on using the SPUs instead of the RSX, but they usually only have a couple people (or even just a single person) working on it.
Actually, I think Sony is doing this to get free work from the community. It's no secret that they originally didn't want to put the RSX on the PS3, using the SPUs for everything. However, they didn't want to have to spend the time developing their own 3D library and took the "easy" way out by including an nVidia GPU. Now they're waiting for the community to develop the 3D lib for them, then the next PS3 will drop the RSX to save even more money. Well, it's a (wild and crazy) theory at least. :D
Actually, I think Sony is doing this to get free work from the community. It's no secret that they originally didn't want to put the RSX on the PS3, using the SPUs for everything. However, they didn't want to have to spend the time developing their own 3D library and took the "easy" way out by including an nVidia GPU. Now they're waiting for the community to develop the 3D lib for them, then the next PS3 will drop the RSX to save even more money. Well, it's a (wild and crazy) theory at least. :D
They don't use it directly - they use a Sony library. The idea is by making devs use libraries, Sony can switch (or remove) parts as needed and the games will still work. It's like with the PSP, we don't use the GE directly, poking registers and whatnot - we call the sceGu/sceGe library functions. Or like on a PC where you don't bang on the video card directly (like back in DOS days) - you call DirectX or OpenGL.LionX wrote:don't the ps3 games use the RSX ? if so, removing the RSX will cause compatibly problems.
you work directly on hardware, I think more directly than on PSP. Most of the hardware access is virtualized via the OS, but you stick together the commandbuffer like on psp.
emulating this is similar to emulate a PS2. Sony can't just stick in another driver, although they could try to use different mappings for memory areas, but it's probably damn hard to simulate all those simultanouse hardware counters etc.
I guess, if sony will ever keep compatibility to the PS3, it will use NV hardware again.
@J.F.
I dont think sony really relies on community work. They could hire ppl to write a rasterizer just like intel did ... (my dream job *haha*)
I'm also just one person and wrote my own that rastrizes for spu (I did it for the company I work so I cannot release the source, sorry).
I think it's rather a business decision from sony. I mean, at some point ppl would make their bootloader and port their full game to run on PS3 (why not if it would be all legal to use rsx?) it would be a static console hardware wird no fees to sony.
emulating this is similar to emulate a PS2. Sony can't just stick in another driver, although they could try to use different mappings for memory areas, but it's probably damn hard to simulate all those simultanouse hardware counters etc.
I guess, if sony will ever keep compatibility to the PS3, it will use NV hardware again.
@J.F.
I dont think sony really relies on community work. They could hire ppl to write a rasterizer just like intel did ... (my dream job *haha*)
I'm also just one person and wrote my own that rastrizes for spu (I did it for the company I work so I cannot release the source, sorry).
I think it's rather a business decision from sony. I mean, at some point ppl would make their bootloader and port their full game to run on PS3 (why not if it would be all legal to use rsx?) it would be a static console hardware wird no fees to sony.
When I pay alot, I expect to use everything (gpu+spu's).
True gpu have great assets such as caches and ZCOMP. Unfortunately we don't have true tiles declarations and ZCOMP (even on fw<2.10), which compresses thru hw cirtcuits Z values and allows around 30% bandwidth saving. Tiles have also great internal cache areas for speeding things up and I think that amount is to be considered not consuming vram or normal memory so it's a plus as well.
I still hope we will get full RSX capabilites on PS3 some day.
I'm sure the best recipe is :
- full cache (tiles) and Zcomp usage on RSX
- minimal shader complexity on RSX (to not slow it down)
- all sophisticated pre-calculation on Spe's
Overall, whatever you are using (spe's only, rsx only, or both), the absolute target is to mimic Wipeout HD which dynamically changes horizontal resolution in order to lock up 60fps. That's a true progress, that can't even happen on the 360 hardware...
EDIT: A few details about horizontal resolutions (they are for 1080p and thus the dynamically watered down 1080 scan lines hybrid resolutions).
The list of resolutions ps3 can activate when starting rendering 3D scene are :
720x480 (true 480p)
720x576 (true 576p)
1280x720 (true 720p)
1920x1080 (true 1080p)
1600x1080
1440x1080
1280x1080
960x1080
So I guess you have to start with true 1080p (so you reserve ram/vram size at max), then you dynamically switch among the following resolutions and select between 960 and 1920 pixels horizontally (the fact that you don't change the vertical resolution probably ensures that no flickering image can happen on hdtv)
But I guess 1080i may be possible as well while changing horizontal resolution.
Interlace seems to be an independant option.
True gpu have great assets such as caches and ZCOMP. Unfortunately we don't have true tiles declarations and ZCOMP (even on fw<2.10), which compresses thru hw cirtcuits Z values and allows around 30% bandwidth saving. Tiles have also great internal cache areas for speeding things up and I think that amount is to be considered not consuming vram or normal memory so it's a plus as well.
I still hope we will get full RSX capabilites on PS3 some day.
I'm sure the best recipe is :
- full cache (tiles) and Zcomp usage on RSX
- minimal shader complexity on RSX (to not slow it down)
- all sophisticated pre-calculation on Spe's
Overall, whatever you are using (spe's only, rsx only, or both), the absolute target is to mimic Wipeout HD which dynamically changes horizontal resolution in order to lock up 60fps. That's a true progress, that can't even happen on the 360 hardware...
EDIT: A few details about horizontal resolutions (they are for 1080p and thus the dynamically watered down 1080 scan lines hybrid resolutions).
The list of resolutions ps3 can activate when starting rendering 3D scene are :
720x480 (true 480p)
720x576 (true 576p)
1280x720 (true 720p)
1920x1080 (true 1080p)
1600x1080
1440x1080
1280x1080
960x1080
So I guess you have to start with true 1080p (so you reserve ram/vram size at max), then you dynamically switch among the following resolutions and select between 960 and 1920 pixels horizontally (the fact that you don't change the vertical resolution probably ensures that no flickering image can happen on hdtv)
But I guess 1080i may be possible as well while changing horizontal resolution.
Interlace seems to be an independant option.
"OTHEROS" uses virtualized hardware. You can bet your grandma that GameOS uses Sony libs, just like the PSP.rapso wrote:you work directly on hardware, I think more directly than on PSP. Most of the hardware access is virtualized via the OS, but you stick together the commandbuffer like on psp.
That was my tongue-in-cheek, tinfoil hat theory, and not meant to be taken seriously. :D@J.F.
I dont think sony really relies on community work. They could hire ppl to write a rasterizer just like intel did ... (my dream job *haha*)
Darn! :(I'm also just one person and wrote my own that rastrizes for spu (I did it for the company I work so I cannot release the source, sorry).
That's not likely. The Sony fees are nothing compared to the cost of producing the game in the first place. Why would a company pay twice as much (exaggeration) to replace GameOS (remember that OTHEROS requires you to provide all your own drivers).I think it's rather a business decision from sony. I mean, at some point ppl would make their bootloader and port their full game to run on PS3 (why not if it would be all legal to use rsx?) it would be a static console hardware wird no fees to sony.
Second, your customers won't like it when they have to install the custom launcher and leave GameOS just to play your game. There's a reason Sony made GameOS the default, and made launching OTHEROS a pain.
That's not the point, the point was about "The idea is by making devs use libraries, Sony can switch (or remove) parts as needed and the games will still work". and that's not gonna work, cause whatever way you use to access the hardware, it's in your binary. sony cannot switch any parts or remove anything. sure, sony can try to intercept your commandbuffer to fix all calls to some hardware they 'removed', but I guess that's not what your sentence was about?J.F. wrote:"OTHEROS" uses virtualized hardware. You can bet your grandma that GameOS uses Sony libs, just like the PSP.rapso wrote:you work directly on hardware, I think more directly than on PSP. Most of the hardware access is virtualized via the OS, but you stick together the commandbuffer like on psp.
sorry, i'm not nantively speakin english, I take all of you here seriously all the time ;)That was my tongue-in-cheek, tinfoil hat theory, and not meant to be taken seriously. :D@J.F.
I dont think sony really relies on community work. They could hire ppl to write a rasterizer just like intel did ... (my dream job *haha*)
writing a game engine is also a lot of work, having one person that works fulltime for 6months on 'otheros' for your game and save two persons getting the game stable on a dozen PC configurations is just a win ;)That's not likely. The Sony fees are nothing compared to the cost of producing the game in the first place. Why would a company pay twice as much (exaggeration) to replace GameOS (remember that OTHEROS requires you to provide all your own drivers).I think it's rather a business decision from sony. I mean, at some point ppl would make their bootloader and port their full game to run on PS3 (why not if it would be all legal to use rsx?) it would be a static console hardware wird no fees to sony.
that's my point. blocked RSX access, "painful way to get linux running", it's all to keep their business running. they could for sure bootup linux (or other OSes) from disc with full openGL support.Second, your customers won't like it when they have to install the custom launcher and leave GameOS just to play your game. There's a reason Sony made GameOS the default, and made launching OTHEROS a pain.
To be honest, I dont even understand why they gave us linux support.
Because Ken Kutaragi thought it would lower hacking pressure and it worked. Smart move. But now he's gone and high ranks don't care about Linux much.
In fact many of the best hackers in the world repeatedly warned manufacturers that allowing Linux on their platform would prevent bad things to happen to their product... That's why many of them don't want to even try hacking ps3 now.
In fact many of the best hackers in the world repeatedly warned manufacturers that allowing Linux on their platform would prevent bad things to happen to their product... That's why many of them don't want to even try hacking ps3 now.
Last edited by ps2devman on Wed May 27, 2009 2:20 am, edited 1 time in total.
The PSP doesn't use static linking for the system libraries, and I doubt the PS3 does as well. Whatever library is used for graphics in the PS3 GameOS would be dynamically linked when the game loads. You don't want static libs for a modern console as that means no bugs can be fixed by just updating the system. The fact that Sony has stated in nearly every update that bugs related to games are fixed proves that the libraries are dynamically linked. Obviously, that doesn't help if the bug is in the game, just in the system libraries.rapso wrote:That's not the point, the point was about "The idea is by making devs use libraries, Sony can switch (or remove) parts as needed and the games will still work". and that's not gonna work, cause whatever way you use to access the hardware, it's in your binary. sony cannot switch any parts or remove anything. sure, sony can try to intercept your commandbuffer to fix all calls to some hardware they 'removed', but I guess that's not what your sentence was about?J.F. wrote:"OTHEROS" uses virtualized hardware. You can bet your grandma that GameOS uses Sony libs, just like the PSP.rapso wrote:you work directly on hardware, I think more directly than on PSP. Most of the hardware access is virtualized via the OS, but you stick together the commandbuffer like on psp.
No problem. I should have put more smileys around it to help make it clear. :)sorry, i'm not nantively speakin english, I take all of you here seriously all the time ;)That was my tongue-in-cheek, tinfoil hat theory, and not meant to be taken seriously. :D@J.F.
I dont think sony really relies on community work. They could hire ppl to write a rasterizer just like intel did ... (my dream job *haha*)
Well, Sony put a lot of effort into making GameOS attractive to developers, so I wouldn't expect established development teams to bother with their own. The only people who would be interested won't have the resources to do it.writing a game engine is also a lot of work, having one person that works fulltime for 6months on 'otheros' for your game and save two persons getting the game stable on a dozen PC configurations is just a win ;)That's not likely. The Sony fees are nothing compared to the cost of producing the game in the first place. Why would a company pay twice as much (exaggeration) to replace GameOS (remember that OTHEROS requires you to provide all your own drivers).I think it's rather a business decision from sony. I mean, at some point ppl would make their bootloader and port their full game to run on PS3 (why not if it would be all legal to use rsx?) it would be a static console hardware wird no fees to sony.
As ps2devman stated, to cut down on the desire to hack GameOS. For nearly all purposes of homebrew, the existing linux for the PS3 is adequate. You can run media players, lots of games, and anything not requiring hardware 3D. The latest Xubuntu on the PS3 is really great. The only thing missing is hardware 3D, so I can't play ioquake3 on it. I can run emulators, play other games like pingus and Maelstrom, and run FireFox, OpenOffice, IM programs, GIMP, and nearly everything else in the repo. At full speed.that's my point. blocked RSX access, "painful way to get linux running", it's all to keep their business running. they could for sure bootup linux (or other OSes) from disc with full openGL support.Second, your customers won't like it when they have to install the custom launcher and leave GameOS just to play your game. There's a reason Sony made GameOS the default, and made launching OTHEROS a pain.
To be honest, I dont even understand why they gave us linux support.
People still want hardware 3D, but having linux means that the desire is less than the hassle of trying to break GameOS for the majority of the devs who would otherwise be doing nothing but hacking away at GameOS.
I dont even use any of those libs, done all my homebrew-commandbuffer creation by hand, the only thing that is handled by the OS is the framebuffer swap, it's probably the same way done on ps3. (sadly, if I were a signed PS3 developer, I wouldn't be allowed to tell you that it really is that way ;) )J.F. wrote:The PSP doesn't use static linking for the system libraries, and I doubt the PS3 does as well.rapso wrote:That's not the point, the point was about "The idea is by making devs use libraries, Sony can switch (or remove) parts as needed and the games will still work". and that's not gonna work, cause whatever way you use to access the hardware, it's in your binary. sony cannot switch any parts or remove anything. sure, sony can try to intercept your commandbuffer to fix all calls to some hardware they 'removed', but I guess that's not what your sentence was about?J.F. wrote: "OTHEROS" uses virtualized hardware. You can bet your grandma that GameOS uses Sony libs, just like the PSP.
that fix is a FW that includes a patch for the game binary. sure, that can be done, but just in cooperation with the developer.Whatever library is used for graphics in the PS3 GameOS would be dynamically linked when the game loads. You don't want static libs for a modern console as that means no bugs can be fixed by just updating the system. The fact that Sony has stated in nearly every update that bugs related to games are fixed proves that the libraries are dynamically linked. Obviously, that doesn't help if the bug is in the game, just in the system libraries.
it's a lot of money that you have to give to sony. devkits, license, per-unit fees, TRC. I think a lot of (little) companies would love to skip all those, even though it's a lot of work that would have to be done to get some bootable game.Well, Sony put a lot of effort into making GameOS attractive to developers, so I wouldn't expect established development teams to bother with their own. The only people who would be interested won't have the resources to do it.writing a game engine is also a lot of work, having one person that works fulltime for 6months on 'otheros' for your game and save two persons getting the game stable on a dozen PC configurations is just a win ;)That's not likely. The Sony fees are nothing compared to the cost of producing the game in the first place. Why would a company pay twice as much (exaggeration) to replace GameOS (remember that OTHEROS requires you to provide all your own drivers).
Personally, I prefer the OtherOS over linux on PS3 for developing games.
so we should stick together and make some SPU-GL running *haha*As ps2devman stated, to cut down on the desire to hack GameOS. For nearly all purposes of homebrew, the existing linux for the PS3 is adequate. You can run media players, lots of games, and anything not requiring hardware 3D. The latest Xubuntu on the PS3 is really great. The only thing missing is hardware 3D, so I can't play ioquake3 on it. I can run emulators, play other games like pingus and Maelstrom, and run FireFox, OpenOffice, IM programs, GIMP, and nearly everything else in the repo. At full speed.that's my point. blocked RSX access, "painful way to get linux running", it's all to keep their business running. they could for sure bootup linux (or other OSes) from disc with full openGL support.Second, your customers won't like it when they have to install the custom launcher and leave GameOS just to play your game. There's a reason Sony made GameOS the default, and made launching OTHEROS a pain.
To be honest, I dont even understand why they gave us linux support.
People still want hardware 3D, but having linux means that the desire is less than the hassle of trying to break GameOS for the majority of the devs who would otherwise be doing nothing but hacking away at GameOS.
yeah, the frontend with all those states etc is what takes time to implement (and verify/fix), the transformation+rasterization is kinda kids play compared to that.J.F. wrote::)rapso wrote: so we should stick together and make some SPU-GL running *haha*
I doubt a couple folks could make a replacement OpenGL in a short period of time (leave that to the Cell-MESA project), but something simpler would be handy for some devs.
do u think the GUM lib from psp would be a place to start? (I never used it, but it looked ogl alike)
Maybe. Or maybe the GE lib... just enough to get PSPGL compiling. :)rapso wrote:yeah, the frontend with all those states etc is what takes time to implement (and verify/fix), the transformation+rasterization is kinda kids play compared to that.J.F. wrote::)rapso wrote: so we should stick together and make some SPU-GL running *haha*
I doubt a couple folks could make a replacement OpenGL in a short period of time (leave that to the Cell-MESA project), but something simpler would be handy for some devs.
do u think the GUM lib from psp would be a place to start? (I never used it, but it looked ogl alike)
Or maybe Vincent.
http://www.vincent3d.com/Vincent3D/index.html