10~12 out of 32MB of PSP RAM not accessible to the devs!

[Farid]

No biggie since the days of Shenmue (or maybe even before?)...

Before... long time before. (A lot of PS1 used this kind of techniques)

 

[Fleet-C]

I just remenberd one thing, The zodiac is Palm based and also needs 12MB of the main RAM, could that mean that sony has some kind of Palm/Clie "keknel" in there?

 

[Phil]

london-boy:

^^ true. We don't know if that is true, and if it is, what purpouse that OS serves. Either way, I was just looking for possible reasons as to why it could be that big. I do agree though that it wouldn't be necessary, as the memory can be just as static with its full 32 MB of RAM. Anyway, hopefully we'll have some answers soon enough.

 

[London Geezer]

I just remenberd one thing, The zodiac is Palm based and also needs 12MB of the main RAM, could that mean that sony has some kind of Palm/Clie "keknel" in there?

12MB Kernel?

That is one big fat kernel there...

 

[marconelly!]

If true, that's still way better than the old 8MB spec, as it would leave ~20MB for game code and assets now. That should still make it possible to mostly keep PS2-like assets due to texture compression and ability to use a bit lower res textures and lower detail models. Still, I find it kinda weird that they waste 12 MB on seemingly nothing that can't be stored in ROM.

BTW, besides the few interactive displays of game engines (2D RPG, Ape Escape, MGS Acid) and the 4 tech demoes, none of the footages of games shown on PSPs were PSP generated. They are all PS2 footages. So I was mistaken yesterday when I replied to Panajev about that F1 game. Sorry.

Hehe, luckily those tech demos were actually the most impressive footages anyways! )

What about stuff that is obviously PSP bound like Wipeout Pure, or that Mercury game where you control the ball of mercury in the marble madness-like world?

 

[Fafalada]

Even with Palm OS in there it just doesn't make sense to run the full thing during games. You could likely stash what needs to be resident for power and other monitoring into less then 1MB, the rest could very easily sit on flash and upload itself to memory when you close the game.
Unless of course they think we need to run multiple games simultaneously or something and there should be a full multitasking OS running all the time

Or maybe browse the net during gaming... heck, I just thought of a reason why they absolutely Need dual screens. How am I supposed to read gamefaqs at the sametime while playing if not with another screen?

 

[McFly]

Or maybe browse the net during gaming... heck, I just thought of a reason why they absolutely Need dual screens. How am I supposed to read gamefaqs at the sametime while playing if not with another screen?

LOL, they better make games where I don't need Gamefaq.

Fredi

 

[London Geezer]

Or maybe browse the net during gaming... heck, I just thought of a reason why they absolutely Need dual screens. How am I supposed to read gamefaqs at the sametime while playing if not with another screen?

LOL, they better make games where I don't need Gamefaq.

Fredi

And u think u're gonna finish Ultra Final Fantasy Portable Special Platinum Edition Plus 2004 without a guide? U naive carbon-based creature.

 

[McFly]

And u think u're gonna finish Ultra Final Fantasy Portable Special Platinum Edition Plus 2004 without a guide? U naive carbon-based creature.

Till now I finished every Final Fantasy without a guide, sure I did not get every hidden special ultra hyper magic power item, but I'm not one of them that need to see every pixel of a game anyway.

Fredi

 

[Ty]

Depends on how the data is stored on the UMD or how the application fetches the data. I guess in a game like SSX or Jak II where the game console is constantly fetching data, that (heavily compressed) data could be very well stored temporarely on a buffer first (perhaps those 10-12 MB) to reduce constant loading.

They are discouraging Devs from spooling.

 

[marconelly!]

They are discouraging Devs from spooling.

Well, obviously they don't want the disc to spin all the time, as that would eat the battery, but with 12MB buffer, they could spin the disc, fill the buffer, then power it down for the time being. Now, I'm not sure how it works on home consoles exactly, and how big buffer they use, but streaming games, like Jak 2, are spinnging the disc and rading data *constantly*.

I think games like SSX, or Wipeout will definitely have to stream the music - their atmosphere depends way too much on licensed soundtrack, IMO - but will also have the option to disable music completely to preserve battery life.

 

[jvd]

I'm not angry with you, I'm practising to be prepared to get really angry with Sony if this DOES happen to be true

Ah it came across as how can u be so stupid not to know that a codec is small. And the answer is my mother dropped me alot and then i started living on paintchips .

 

[Shogmaster]

If true, that's still way better than the old 8MB spec, as it would leave ~20MB for game code and assets now. That should still make it possible to mostly keep PS2-like assets due to texture compression and ability to use a bit lower res textures and lower detail models. Still, I find it kinda weird that they waste 12 MB on seemingly nothing that can't be stored in ROM.

BTW, besides the few interactive displays of game engines (2D RPG, Ape Escape, MGS Acid) and the 4 tech demoes, none of the footages of games shown on PSPs were PSP generated. They are all PS2 footages. So I was mistaken yesterday when I replied to Panajev about that F1 game. Sorry.

Hehe, luckily those tech demos were actually the most impressive footages anyways! )

What about stuff that is obviously PSP bound like Wipeout Pure, or that Mercury game where you control the ball of mercury in the marble madness-like world?

On yeah... I forgot about those two and the two sports game stuff that isn't obviously from PS2. The things is, that all those footages shown are in video format running on the PSP, so you can't tell if the footage was generated on PSP hardware and then recorded on video or just sped up emulated stuff from the dev kits.

All I know for sure is that only PSP generated real time stuff on the floor is the 4 interactive tech demoes (Globe, city scape, running boy, and the duck in sink), and the 4 real time game engine demoes (semi-interactive), which were Ape Escape, Hot shots golf, MGS Acid, and the unknown 2D RPG. The rest are FMVs running through the UMD or the memory stick.

-Shogmaster from the show floor

 

[Farid]

On yeah... I forgot about those two and the two sports game stuff that isn't obviously from PS2. The things is, that all those footages shown are in video format running on the PSP, so you can't tell if the footage was generated on PSP hardware and then recorded on video or just sped up emulated stuff from the dev kits.

All I know for sure is that only PSP generated real time stuff on the floor is the 4 interactive tech demoes (Globe, city scape, running boy, and the duck in sink), and the 4 real time game engine demoes (semi-interactive), which were Ape Escape, Hot shots golf, MGS Acid, and the unknown 2D RPG. The rest are FMVs running through the UMD or the memory stick.

You scared me for a moment i thought that all the games were running on PS2. (Obviously some were actually PS2 games, Axel Impact look too good to be a PSP version of the game)
So it really might be videos from a speed-up PSP emulation or videos from the hardware Dev-kits.

 

[aaaaa00]

Depends on how the data is stored on the UMD or how the application fetches the data. I guess in a game like SSX or Jak II where the game console is constantly fetching data, that (heavily compressed) data could be very well stored temporarely on a buffer first (perhaps those 10-12 MB) to reduce constant loading.

They are discouraging Devs from spooling.

Yup. The only way the quoted battery life numbers make sense (8-10 hours gameplay, 8 hours MP3, 2.5 hours movie) is if the UMD drive sucks power like crazy.

If that's the case, streaming will just destroy the battery life.

If you ask me, the battery life numbers are going to be optimistic anyway.

 

[Guden Oden]

Well, obviously they don't want the disc to spin all the time, as that would eat the battery, but with 12MB buffer, they could spin the disc, fill the buffer, then power it down for the time being.

And what if the player reverses direction? The disc would spin right back up again and read in the previous 10-12MBs that were previously tossed out. It's not a real gain.

I think games like SSX, or Wipeout will definitely have to stream the music - their atmosphere depends way too much on licensed soundtrack

Compressed audio stored in memory... An entire soundtrack at a suitable quality for a handheld need only take 1.5MB at most.

 

[Ali-G]

Compressed audio stored in memory... An entire soundtrack at a suitable quality for a handheld need only take 1.5MB at most.

1.5MB is maybe good enough for a couple of songs at half decent quality (25kbit/s). People will expect far better then GBA sound quality on PSP games.

A soundtrack would be around 10-12 songs. So what bitrate do think is ok? 10-12 songs stored as 1.5MB is around 5kbit/s. That's not close to good enough for PSP games.

 

[Fafalada]

A soundtrack would be around 10-12 songs. So what bitrate do think is ok? 10-12 songs stored as 1.5MB is around 5kbit/s. That's not close to good enough for PSP games.

An average song is 3-4minutes long. Firing up the disc every 4 minutes for a 1-2second load will drain the fraction of power compared to spinning it constantly. And 1.5MB per song should suffice for pretty good quality.

Moreover, many modern songs (particularly much of the stuff in say, SSX3) could be stored synthesized instead of raw sound data, making the required size per song that much smaller, at same or better quality.

 

[Panajev2001a]

Well, obviously they don't want the disc to spin all the time, as that would eat the battery, but with 12MB buffer, they could spin the disc, fill the buffer, then power it down for the time being.

And what if the player reverses direction? The disc would spin right back up again and read in the previous 10-12MBs that were previously tossed out. It's not a real gain.

I think games like SSX, or Wipeout will definitely have to stream the music - their atmosphere depends way too much on licensed soundtrack

Compressed audio stored in memory... An entire soundtrack at a suitable quality for a handheld need only take 1.5MB at most.

Guden, I would guess you would buffer data in the areas around the player and based on the proximity of the player to a certain location, you could buffer a bit more of certain rooms compared to others.

If you are in huge room with two doors, each at one end of the room, if you find yourself at one end of the room where one door is then you could fill the buffer with the data of the room you would enter passing through that specific door.

Alternatively, since the room you are in is already in RAM ( you are working on it ), you could divide the buffer in all the possible new areas the player could enter from that location.

 

[creon100]

If you are in huge room with two doors, each at one end of the room, if you find yourself at one end of the room where one door is then you could fill the buffer with the data of the room you would enter passing through that specific door.

Alternatively, since the room you are in is already in RAM ( you are working on it ), you could divide the buffer in all the possible new areas the player could enter from that location.

I think the second scenario is much more likely and feasible, at least in terms of conserving battery life. Loading the data for both possible rooms (ie. buffering all possible exit possibilities from the current location) would cut down on disc access more than pre-loading the next location based on where you are in the room. After all, if it's an action game you could possibly be moving all over the room while you take out the baddies, in the first scenario that disc would be spinning like crazy as you changed position and it said, "let me buffer this! Oh no he moved, now I need this instead! Damn you stay still, now I need this!!"

If you keep a "buffer window" of locations you also cut down on the amount you need to load, because the room your exiting would stay in the buffer anyway since it's obviously a possible location you could enter from the new room you're entering.