From http://pc.watch.impress.co.jp/docs/2005 ... gai166.htm:
ALLEGREX
Interesting...
'utility applets'
- Good to have a name to call them.
libgu/libgum/libgmo
- I wonder if these are provided by the game, or by the firmware? Either way, it is good to see Sony providing an easier environment for developers.
'audio resides in main memory'
- Along with vram mapped into main memory it seems a lot like uma is the name of the game on the psp.
'optimally, use LBAs to access if at all possible'
'multiple copies so that you can get the closest one'
- Hopefully this will put a big snag in the warez0rs trying to run stuff from anything other than the umd.
'vector floating point unit, macromode only'
'no dedicated memory'
- Macromode, and no dedicated memory? Should be easier for developers to get into than the vu1 on the ps2.
'half float'
- Strange, I guess this is just for packed geometry...
'utility applets'
- Good to have a name to call them.
libgu/libgum/libgmo
- I wonder if these are provided by the game, or by the firmware? Either way, it is good to see Sony providing an easier environment for developers.
'audio resides in main memory'
- Along with vram mapped into main memory it seems a lot like uma is the name of the game on the psp.
'optimally, use LBAs to access if at all possible'
'multiple copies so that you can get the closest one'
- Hopefully this will put a big snag in the warez0rs trying to run stuff from anything other than the umd.
'vector floating point unit, macromode only'
'no dedicated memory'
- Macromode, and no dedicated memory? Should be easier for developers to get into than the vu1 on the ps2.
'half float'
- Strange, I guess this is just for packed geometry...
It may not put a snag in.. It depends on how the game developers code the games.ooPo wrote:Interesting...
'optimally, use LBAs to access if at all possible'
'multiple copies so that you can get the closest one'
- Hopefully this will put a big snag in the warez0rs trying to run stuff from anything other than the umd.
Basically the multiple copies are used as "cache" mode..
What I mean by this is by having multiple copies of the program scattered around the disc, the UMD can read one of the "copies" and resume from where it was at from a data file that happens to be next to that copy.. It doesnt have to go back to the original copy of the program..
[program] [animation file] [character data] [program] [sound file] [animation file] [program]
Even if it starts up using the first program, and then if it has to read the sound file thats further in the UMD (closer to the middle or edge) it can then read the program right before the sound file and resume from it..
Theres ways around it, but I'm not going to mention them. Its purpose seems to be just to help improve UMD response speed and reduce delay by reading from the UMD.
But honestly, there may not be that many instances of developers doing this, depending on the game.. I.e. multiple copies of programs will reduce space on the UMD if the game is large.
Well, Sony was referring more to data, than code. Code is loaded wholely into RAM with PRX modules being the exception, so seeking is not required for a program at all once execution starts (with the exception of PRX modules, but the limited RAM/etc might be part of the cause of long loading times, having to swap around PRX files).fireether wrote:What I mean by this is by having multiple copies of the program scattered around the disc, the UMD can read one of the "copies" and resume from where it was at from a data file that happens to be next to that copy.. It doesnt have to go back to the original copy of the program..
<snip>
But honestly, there may not be that many instances of developers doing this, depending on the game.. I.e. multiple copies of programs will reduce space on the UMD if the game is large.
The second point is pretty right-on though. Developers might shy away from it because multiple copies is /bad/ in a lot of cases.
On the other hand, LBAs have been in PS2 games quite often for awhile now. While it hasn't been terribly successful in preventing piracy there, in this case it is very likely the reason why the warez junkies have gotten stuff like Wipeout to boot up until it has to load the main screen, and then it locks. This explains it, and makes me smile, knowing they are pretty much boned for quite awhile (at least). ;)
just want to remind you that especially when it comes to security issues Sony would bluntly feed false information...
and I may not be as good as you, but those "warez junkies" will probably mount the iso of umd on a virtual drive and assign it a umd device handler... so I may not know the PS2 well, but I can't see how any of this will make any difference to them =/
and I may not be as good as you, but those "warez junkies" will probably mount the iso of umd on a virtual drive and assign it a umd device handler... so I may not know the PS2 well, but I can't see how any of this will make any difference to them =/
Well, LBAs aren't security issues, they are speed issues that just happen to break when you change the layout of the disc even slightly, which is a possible result of it being pirated.
With the ISO possibility, that is fairly remote, they essentially will be stuck in the same way homebrew is, doing more work than the homebrew groups, for less gain. They have to overcome the same signed code hurdles, and then on top of that, figure out how to hijack the UMD handler from the kernel. Even now they are having problems doing things like that reliably on the PS2, because you practically have to have the same knowledge of the system as one of Sony's firmware writers. (i.e. by the time they figure it out, the console will be nearly dead, which is about as secure as any money-focused company could hope for)
With the ISO possibility, that is fairly remote, they essentially will be stuck in the same way homebrew is, doing more work than the homebrew groups, for less gain. They have to overcome the same signed code hurdles, and then on top of that, figure out how to hijack the UMD handler from the kernel. Even now they are having problems doing things like that reliably on the PS2, because you practically have to have the same knowledge of the system as one of Sony's firmware writers. (i.e. by the time they figure it out, the console will be nearly dead, which is about as secure as any money-focused company could hope for)