128mb Of Ram...

[jdh2550]

To prophet, atomicthumbs and others who chose to simply answer the question - many thanks. It's a system limitation.

Simple question. Simple answer.

The rest of you - take a Valium.

And to my friend Exophase - yes I am a developer. Why are you so arrogant in your replies?

I decided to do some more research:

1) couldn't find anything on OMAP 3430 address bus width
2) did find this picture: OMAP3430 System Diagram
3) Surprised to see that it shows a mobile DDR interface - I don't know what SDRC or GPMC refer to. But seeing as SDRC is for Mobile DDR and GPMC is for Flash I presume that it's the capabilities of this "SDRC" component that is of interest in determining the max capacity addressable.
4) Searching for information on Mobile DDR does show large capacity (1GB) modules - however, I recognize that doesn't mean that the p&|a can use those modules.
5) couldn't find anything on Mobile DDR power requirements specifically (plenty of folks just say "low power"): http://www.micron.com/products/dram/mobiledram/index

Anyway - I could spend hours more researching this stuff. Or I could ask a simple question and get jumped upon for daring to ask something so simple...

 

[jdh2550]

Sorry I missed Pickle's reply to the thread. Is Michael the same as MWeston? The chip is soldered on (as I expected) - but it is probably still a mobile DDR chip (as per the OMAP system diagram). So, it would seem to leave open the ability for a higher capacity in the future (if it is deemed necessary by Craig et. al - we already know several other points of view on this).

p.s. where do I go to get my free GP32? I notice that my side bar now says "GP32 user" and I'd hate to be accused of mis-representation...

 

[Exophase]

And to my friend Exophase - yes I am a developer. Why are you so arrogant in your replies?

That was a question, not an implication that you aren't one. I'm sorry you took it that way. Maybe as a developer you could explain why you want so much memory.

Why do you think I'm being arrogant? Or more so than you are. You might only want answers from the main involved, but if you're entitled to question them then I think we're entitled to question you.

Repeatedly telling people to get off your back, "take a valium", and insist you're not being critical (which I think you are, implied or otherwise) does not actually make you more reasonable than those you're taking issue with.

 

[Pickle]

Sorry I missed Pickle's reply to the thread. Is Michael the same as MWeston? The chip is soldered on (as I expected) - but it is probably still a mobile DDR chip (as per the OMAP system diagram). So, it would seem to leave open the ability for a higher capacity in the future (if it is deemed necessary by Craig et. al - we already know several other points of view on this).

Yeah it's him, I basically had the same questions you did. But I went direct to the source. The memory will be soldered onto the soc, so unless your very fortunate your stuck with 128 mb. It sounded like to me the soc+ddr may have already been soldered together.
I wouldnt count on any changes to the memory. The only way we will get more memory is with a second generation pandora (mk2).

 

[jdh2550]

Maybe as a developer you could explain why you want so much memory.

I gave one example in my initial post.

Why do you think I'm being arrogant? Or more so than you are.

Because one of your first lines was along the lines of "this is not a UMPC meant for running bloated x86 applications - don't believe whatever else you've heard". Taking that and splitting it apart: First the UMPC stuff: Craig has said in a number of different sources that it is a flexible computing platform (take the website for example: "It is designed as an ultra portable open source computer with gaming controls"). Your reply arbitrarily put you at odds with the stated design intent - and that seems arrogant. Next the bloated x86 stuff - not particularly relevant and appears to suggest that all x86 software is bloated - another arrogant position to take.

You might only want answers from the main involved, but if you're entitled to question them then I think we're entitled to question you.
Yes, you are entitled to question me - but don't put forth your point of view as hard fact - when, like mine, it's just a point of view. The reason I posed the question to the dev team is because, let's face it, the rest of us are guessing (yes, some are educated guesses).

Repeatedly telling people to get off your back, "take a valium", and insist you're not being critical (which I think you are, implied or otherwise) does not actually make you more reasonable than those you're taking issue with.

I certainly intend to be critical of you and others that posted critical stuff (alas, as I may have mentioned elsewhere my MO is to pour gas onto flames rather than water). However, what was critical (in a negative sense rather than a constructive sense) in my original post?

Still - this is all rather pointless - don't you think?

OK - so now why does bb code hate me? I only want ot be loved... Really!

Thanks to nubie for pointing out my bbcode mistake!

Yeah it's him, I basically had the same questions you did. But I went direct to the source.

Thanks - case closed.

 

[Exophase]

I gave one example in my initial post.

I'm looking for something more concrete than a minimum requirement, or maybe to put it other terms, an explanation of why a GUI should require hundreds of MB of RAM (also bearing in mind that this will be for a lower resolution than what most have used on PCs for years). I take many minimum requirements with a grain of salt - who is using a PC now with less than 256MB of RAM?

Because one of your first lines was along the lines of "this is not a UMPC meant for running bloated x86 applications - don't believe whatever else you've heard". Taking that and splitting it apart: First the UMPC stuff: Craig has said in a number of different sources that it is a flexible computing platform (take the website for example: "It is designed as an ultra portable open source computer with gaming controls"). Your reply arbitrarily put you at odds with the stated design intent - and that seems arrogant.

I don't think that it does. Although "ultra portable open source computer" suggests "UMPC" on a literal level I would highly disagree that that's what it means. UMPC means just that, a very small PC, which would necessarily have to be x86 based.

Next the bloated x86 stuff - not particularly relevant and appears to suggest that all x86 software is bloated - another arrogant position to take.

I said heavy weight, but take it to mean what you will. Of course all x86 software isn't bloated, but it also isn't written with low memory requirements in mind because it isn't necessary. ARM software more often is, and the end result is that less memory is required (because less was available in the first place). So please give an example of where more than 128MB of RAM is necessary aside from accommodating software that until proven otherwise may be demanding more memory than is really needed.

It may mean that Pandora doesn't end up getting as many quick ports as it would otherwise, but that could be a good thing too.

Yes, you are entitled to question me - but don't put forth your point of view as hard fact - when, like mine, it's just a point of view. The reason I posed the question to the dev team is because, let's face it, the rest of us are guessing (yes, some are educated guesses).

Barring disagreement on what a UMPC is (which I don't think should be so up to debate) I don't think that it's anything less than hard fact to state that the Pandora isn't one.

I certainly intend to be critical of you and others that posted critical stuff (alas, as I may have mentioned elsewhere my MO is to pour gas onto flames rather than water). However, what was critical (in a negative sense rather than a constructive sense) in my original post?

As Alex. said, I do think you were criticizing the Pandora for not having more memory. What you wanted is an explanation for this, and I don't think "why does it need more than 128MB?" would have been sufficient.

Still - this is all rather pointless - don't you think?

Let's be honest, if either of us really felt that way we wouldn't be replying to each other :B

OK - so now why does bb code hate me? I only want ot be loved... Really!

Tell me about it, after a certain number of quotes or post length or something they all stop working and I have to split/merge my posts

 

[Squidge]

The cores since ARM7 at the very least have 32 bits of address going out the chip. Indeed then the SoC designer can decide to get rid of some bits

You may want to rephrase that before people get the wrong end of the stick. ARM don't make chips, they make IP. Its upto the chip designer to decide what to give access to.

 

[yaustar]

Squidge, you have Exophase as the author of all the quotes in your last reply rather then jdh2550.

 

[Exophase]

Squidge, you have Exophase as the author of all the quotes in your last reply rather then jdh2550.

And you called me Squidge, so we're even XD

 

[yaustar]

Squidge, you have Exophase as the author of all the quotes in your last reply rather then jdh2550.

And you called me Squidge, so we're even XD

Oops. It is these fricking Guru badges that confused me :S. (And stupid widescreens that have no vertical space)

 

[jdh2550]

freakin' quotes still busted for me - oh well...

1- Whether the Ubuntu OS used as an example is efficiently coded or not is not relevant to me. Nor is trying to determine how many MB should be used for the OS. Nor is figuring out if their "requirements" are for OS + plugins (or whatever you want to call stuff that can be easily trimmed out). What is relevant to me is that I'd like to run it on a p&|a and, it would seem that with 128MB RAM I won't be able to. I want to run it so I can play with it and see if it's something that I might want to use - just like most folks go through a bunch of Linux distros before they choose the one they want.

2- Well, there's one difference. I don't think PC (personal computer) means x86 based. Certainly it is common usage these days. However, look at the moniker "PC" as used by Apple - they take it to mean a "Wintel" setup (x86 running a Microsoft OS). Whereas the EEE is x86 and runs Linux. So, is the EEE not a UMPC? Mere semantics - I take "ultra portable xxxx computer" to the same as "ultra mobile xxxx computer". Seems reasonable to me. Doesn't seem so to you. Until UMPC has an IEEE definition one needs to be generous to the user and look at the context.

3- Fair enough - I misunderstood. You don't think all x86 software is bloated. However, is it fair to say that you do seem to think most modern GUIs (whether Windows or *nix based) are bloated? That still seems like a pretty arrogant position to take.

4- "please give an example of where more than 128MB of RAM is necessary aside from accommodating software that until proven otherwise may be demanding more memory than is really needed." Well, now that would be rather difficult wouldn't it? Do you want a line by line code review of the Ubuntu Mobile UI? How else can I satisfy "until proven otherwise"?

5- You refer to not getting quick ports as possibly being a good thing. This would seem to be a rather different stance than most Linux distros take (and I realize I'm crossing over between distro and HW). Most folks are interested in the flexibility to run the most stuff possible and to choose to weed out the dross themselves. I'm certainly interested in the openness of the platform because of that. And in my mind that doesn't mean I should go buy a laptop (to answer others P.O.V on the subject).

6- We don't agree on UMPC and UMPC is not a standard definition. I think "ultra mobile ..... computer" (UMPC minus one word) and "ultra portable .... computer" (Pandora definition minus two words). So, it would be wise to use UMPC with a looser definition rather than a non-agreed-upon tighter definition. This disagreement on the usage of UMPC is trivial but mostly it "sparked" this debate.

7- It wasn't my intent for my post to be negative criticism.

8- Do I think this is important? No I'm just a stubborn SOB - I expect you are to (but I could of course be wrong).

 

[Tobriand]

Not going to go into the whole thing, but it struck me that the two points below warranted a response.

4- "please give an example of where more than 128MB of RAM is necessary aside from accommodating software that until proven otherwise may be demanding more memory than is really needed." Well, now that would be rather difficult wouldn't it? Do you want a line by line code review of the Ubuntu Mobile UI? How else can I satisfy "until proven otherwise"?

5- You refer to not getting quick ports as possibly being a good thing. This would seem to be a rather different stance than most Linux distros take (and I realize I'm crossing over between distro and HW). Most folks are interested in the flexibility to run the most stuff possible and to choose to weed out the dross themselves. I'm certainly interested in the openness of the platform because of that. And in my mind that doesn't mean I should go buy a laptop (to answer others P.O.V on the subject).

In the case of the former, whilst there's no way I can comment on the situation with Ubuntu mobile, I'd like to draw your attention to the original sterling work done on the port of Beats of Rage to the GP32 by Squidge a few years back. The official BoR requirements stated, if I recall correctly, a minimum of 64mb of ram (it may even have been 128mb). This was cited as a very good reason why the GP32 would never see a port. Until Squidge came along and not only made it run using less than the 8mb available on the GP32, but also introduced a few modifications to the code involving multiple characters that meant the GP32 version could handle WAY more characters than the PC one (or something like that).

Now Beats of Rage is not Ubuntu. But it still stands as a very good example that memory requirements can, at least some of the time, be very very drastically reduced from the estimates by the original developers, if they're attacked with that paticular thing in mind.

In the case of the latter, quick ports are great, early in a device's lifespan. But they are almost always very inefficient, and rarely are tuned to the hardware they end up on, if the GP32 and (especially) GP2x are examples. Compare NightKnight's ports of Snes9x within the first couple of weeks of the GP2x's existence. They *ran*, and they ran most games at a playable speed. But *nothing* like as well as PocketSnes now does. And since you'd have to overclock to ~300MHz for near full speed, battery life always took a hit by using the quick ports. Same will be true of Pandora - quick ports are good, but they should, ideally, be superceded by purpose-built code as and when people understand the machine enough to build code purposefully for it. This goes even more for standard apps where, at the very leat, input methods really ought to be finetuned to the system it's turning up on. At least if you want homebrew to look as polished as commercial stuff does, which I'd rather like, I must say...

 

[God Ginrai]

In the case of the former, whilst there's no way I can comment on the situation with Ubuntu mobile, I'd like to draw your attention to the original sterling work done on the port of Beats of Rage to the GP32 by Squidge a few years back. The official BoR requirements stated, if I recall correctly, a minimum of 64mb of ram (it may even have been 128mb). This was cited as a very good reason why the GP32 would never see a port. Until Squidge came along and not only made it run using less than the 8mb available on the GP32, but also introduced a few modifications to the code involving multiple characters that meant the GP32 version could handle WAY more characters than the PC one (or something like that).

I think I'll start praying to Squidge to work his miracles multiple times on the Pandora.

-God Ginrai

 

[sukhi-2006]

The 128mb ram is right memory it will do many jobs right end of the day it's an portable games console,well it's not a pc just a powerful portable system.

Look at the list below for various platform mb rams pandora ram isn't bad at all:

1)ds lite 4mb ram
2)psp 32/64mb ram
3)gp2x 64mb ram
4)zodiac 2 128mb ram

 

[jdh2550]

Tobriand,

It is impressive bringing down a 64Mb requirement to an 8Mb total - that must have taken a fair amount of work and dedication. However, if there was more memory available then that extra work might have been able to be spent on the next port (if squidgie was so inspired)

Both your examples are very game oriented and for me (and I realize I'm in the minority), Pandora is first an ultra portable open platform and secondly a game platform. Now, don't get me wrong, I look forward to playing lots of games, but I'm also interested in the other stuff it will do. Don't ask me to be specific - because I don't know yet. There's some really cool stuff out there, and given that the p&|a can be used as a USB host there is an even wider array of uses, easy ports will facilitate that.

At the beginning of this post I wasn't even asking for more memory. I was asking why they chose the 128MB that they did and wondering if future versions could have more. I was fully expecting a very well thought out and definitive answer or even a "it seemed right to us at the time" would have sufficed.

Read the opening line of my first post. I'm still a big fan of what these guys have pulled off - it is quite frankly amazing. I hope they sell 50,000 of these even if they don't change a damn thing.

 

[Frogboy]

Maybe someone will write a ReadyBoost type application.

 

[jdh2550]

The 128mb ram is right memory it will do many jobs right end of the day it's an portable games console,well it's not a pc just a powerful portable system.

Look at the list below for various platform mb rams pandora ram isn't bad at all:

1)ds lite 4mb ram
2)psp 32/64mb ram
3)gp2x 64mb ram
4)zodiac 2 128mb ram

I agree it's generous for a games console (and I never said otherwise). However, the pandora is more than that (as evidenced by the design teams website).

The question being asked (out of curiosity and an eye on the other possible uses of the pandora) is why did they chose 128MB.

 

[Sphinxter]

A 256 meg OS is an immobile turd.

 

[Yrx]

It's a game system. Honestly, yes, that's what it is. It's a fricking DS with a keyboard. 128 MB of RAM is a stupendous amount of memory for anything other than running a Microsoft OS or a heavy Linux distro. And honestly, I bet you could get Ubuntu running on it fine with some tweaking. If you don't want to tweak, and you don't want to make the money-invested initiative to make your own handheld (or for that matter, even buy one more powerful than Pandora), then I don't want to hear it.

The internals of the hardware have been decided on, and for some reason or another, Craigix decided to go with 128 MB. Maybe it's cost for specialized parts, maybe it's current availability of that setup. The distinct idea that's coming across is that doing what you're asking for would delay the launch even further, and maybe drive the price up. If you want to spend more money for more functionality, then please, go ahead and buy one of the many other UMPC's on the market

Most of the attitude I get from the open-source community is gratefulness towards the people that make it happen, and excitement over new developments. And that's the way it should be. Besides individual opinion, none of us are entitled to anything at all. Especially since none of us have even bought anything yet. For a businessman, Craigix has been incredibly open-eared to the community. But he can't give us everything we want, especially when it exceeds the bounds of physical possibility or fiscal reasonability.

And if Craigix or anyone else involved reads this, I would like to tell them once again how grateful I am for someone who will do so much for the community. I'm sure many more of us feel the same.

 

[gaterooze]

The question being asked (out of curiosity and an eye on the other possible uses of the pandora) is why did they chose 128MB.

I'd say it is the sweet spot where performance, price, size and power drain converge. Increasing the RAM would have a net negative effect (i.e. the gain in performance is more than outweighed by the increase in price, size and power drain).

Just a guess.