The T5 is a 16MB PDA, and other thoughts...

[slinger]

I've been doing a little programmatical exploration of the T5 memory architecture, and that coupled with some of the information given by representatives from PalmSource have led me to some revelations about PalmOne's representation of this device. Apparently PalmOne took a page from the Sony playbook and decided to trump up the 256 MB of flash RAM as a huge amount of onboard storage, while glossing over or otherwise hiding a rather pertinent issue:

The T5 essentially has only 16 MB of real, static RAM.

The distribution of the flash RAM on the T5 appears to be as follows:

161.2 MB - Internal VFS-like storage area
63.8 MB - User program store (where apps are normally stored)
31 MB - OS system image

The 16 MB of sRAM is allocated as follows:

4 MB - dynamic heap
12 MB - memory protected database cache area, also where feature memory is allocated

Note 1: This explains why there is only 4MB of dynamic heap, as there was only a pool of 16MB of real RAM available and PalmOne couldn't make the dynamic heap too big...

Note 2: Many websites have reported only 53-55MB of program store on the device, but actually the amount is 63.8MB, as the device ships with several applications already installed in the program store area, which the user can delete to bring the available memory up to 63.8MB.

None of the 256MB of flash RAM is directly accessible. Instead, when a user needs to modify a database stored in user program store, that database (or at least the records in question) are copied into the cache area and modified there, and then written back into user program store. It's unclear whether or not the entire database must be copied into the cache area before modification, or if the file system software is smart enough to cache only the modified portions. What is clear is that the amount of memory that can be allocated through the feature memory API is about 10MB, although even that amount is subject reduction through heap fragmentation.

In the end what we have with the T5 is a device that has disguised the fact that it only has 16MB of RAM by allowing users to store their programs in what amounts to ROM instead of RAM. A side benefit of this is that program store can now survive a hard-reset, although this has been called in to question by other members of these forums. One can't help but compare this to the generous 104MB of memory claimed by Sony for the UX50, only to be revealed in the end that it was really a 32MB machine with some extra storage memory.

I can imagine that PalmOne has been breaking its collective arms patting itself on the back with the implementation of this admittedly wonderful technology for smartphones, unfortunately they seem to have missed one rather important point: The T5 is not a smartphone! This technology is basically pointless in a real PDA, and the cost in terms of performance and bad publicity must have surely outweighed any possible cost savings you may have realized by going this route...

-Robert Hildinger

[Lance]

Before I try the hard way, will Power48 run on the T5?

Thanks,
Lance

[slinger]

Before I try the hard way, will Power48 run on the T5?
Thanks,
Lance
The 48SX and 48GX targets should work without any trouble, but the 49G target will likely have problems allocating enough memory to run. I'll likely have to redo the memory allocation routines before the 49G will work consistently.

-Robert Hildinger

[Lance]

The 48SX and 48GX targets should work without any trouble, but the 49G target will likely have problems allocating enough memory to run. I'll likely have to redo the memory allocation routines before the 49G will work consistently.
-Robert HildingerThanks, Robert!

Best regards,
Lance

[FullAction]

This information, coupled with what I've read about the explanations for the global find performance by Ben Crombee, is very disturbing to me. Ben claims, that also Cobalt will use this type of memory, which means that any future Palms will have this configuration, which is backed up by the fact, that the Treo650 will have it. This means that we will have to live with the issues, which come from the flash memory, which is slow application switching, slow global find etc. in future Palms. The further consequences for having actually a low end Palm with 16 MB, are not even known yet. What about larger web pages or large databases?

Well, I, for one, will not go this way. It seems that under these prerequisites, the T3 will be my last Palm.

[Spiral]

How would this format of memory work for OS6, wouldn't multitasking programs require more heap memory? Unless OS6 changes the use of memory, it seems that the T5 would have difficulty gaining enough for several applications

[Lance]

How would this format of memory work for OS6, wouldn't multitasking programs require more heap memory? Unless OS6 changes the use of memory, it seems that the T5 would have difficulty gaining enough for several applicationsVery good point!

Sincerely,
Lance

[FullAction]

It was already explained that Cobalt will not have true multitasking in the sense of the one on the desktop computer, but a possibility of background threads. These threads obviously will have to be programmed with low memory in mind. The only user interaction with background threads is done via these little popup windows (forgot the correct name for it), which saves memory.
OTHO, Palm1 could decide for a full featured 128 real ram/256 flash configuration, but does anybody believe in that given the recent releases?

[WuWei]

Manufacturers are not required to use flash memory, either in OS5.4 or Cobalt.

[FullAction]

Who other manufacturers of PalmOS PDAs are known, after Sony dropped out? There are only a few small smartphone manufacturers as far as I know. Palm1 is tooting the horn with the ability of their new units to keep the data safe even if the battery is empty. I don't think that they have invested in this technology without getting at least 2 years worth of products out of it.

[ballistic]

Who other manufacturers of PalmOS PDAs are known, after Sony dropped out? There are only a few small smartphone manufacturers as far as I know. Palm1 is tooting the horn with the ability of their new units to keep the data safe even if the battery is empty. I don't think that they have invested in this technology without getting at least 2 years worth of products out of it.
Tapwave, and with the Zodiac 1 with 32MB (20MB storage heap) or the Zodiac 2's 128MB (112MB storage heap) of standard non-NAND RAM, 10MB of dynamic heap (both Z1 & Z2), Card Export II by Softick (http://www.softick.com/cardexport2/) offering the same "Flash Drive" capabilities, and dual SD slots, the Zodiac should not be forgotten.
Brian

[FullAction]

Yes, I forgot the Zodiac, but mainly because it's not available in Europe (where I'm located), so it's not an alternative. Additionally the Zodiac seems bulky and awkward to take out during a business meeting. I think it's very well suited for what it was built for (gaming), and I can imagine that a student uses it also for PIM and office, but for using it in a business meeting, it's too console-like for my taste. However, it could turn out as the only alternative, if Tapwave can make it available outside the US..

[jjesusfreak01]

256, ahh, the magic number for all types of memory. It seems, that in the end, the specific amount of memory really boils down to a very clever marketing device. People think 256mb flash cards and thumb drives, or even 256mb of ram for their pc. All dedicated memory, designed for one purpose. No-one but palm could come up with such a magic number to use for marketing their device. People look and say, "Palm has 256mb of memory in their device!, think of how many programs I can store on that!". You dont find Sony doing this. The TH-55 has a full 32 mb of memory dedicated for programs. They even added extra memory, as to not lie about the figures. Is it really so difficult. I guess it would be. I can see the box now... 256mb of internal memory, 210 actually usable, well... thats not completely true, the space is divided into kernel memory, heap memory, os memory, program memory, and some memory that you cant use, but we dont have any idea what its for.

[ballistic]

Yes, I forgot the Zodiac, but mainly because it's not available in Europe (where I'm located), so it's not an alternative.
It will be available in the UK next week on 10/22, and expanding throughout Europe soon.
Additionally the Zodiac seems bulky and awkward to take out during a business meeting. I think it's very well suited for what it was built for (gaming), and I can imagine that a student uses it also for PIM and office, but for using it in a business meeting, it's too console-like for my taste. However, it could turn out as the only alternative, if Tapwave can make it available outside the US..
That's taking this OT, but I'd have to respectfully disagree. Unless you have actually seen the Zodiac in person and handled one, you should reserve judgement ;). I had the same reservations before I actually saw and handled the Zodiac in person, but I was suprised at how thin and sleek it actually is considering it's official dimensions.
I've heard the business meeting argument about the "console-like" appearance before, and again I'd have to disagree. With the muted gray or black finish, it's very subdued and doesn't attract any stares from co-workers. Compared to the bright blue Zire 31/71/72, the Zodiac is quite conservative in appearance. I'm aware of quite a few owners that work in corporate environments, and I have shown my Zodiac 2 to several other "suits", and none of them have ever complained about strange looks or remarks due to the Zodiac's appearance in a business meeting. BTW, the Zodiac has silent/vibrating alarms, something the "corporate" T5 does not. Having a T5's audible alarm go off in one of those meetings would be much more embarrassing than taking out a subdued, metal-bodied Zodiac PDA.
Brian

[tanker_bob]

The T5 essentially has only 16 MB of real, static RAM.
The distribution of the flash RAM on the T5 appears to be as follows:
161.2 MB - Internal VFS-like storage area
63.8 MB - User program store (where apps are normally stored)
31 MB - OS system image
The 16 MB of sRAM is allocated as follows:
4 MB - dynamic heap
12 MB - memory protected database cache area, also where feature memory is allocated
Note 1: This explains why there is only 4MB of dynamic heap, as there was only a pool of 16MB of real RAM available and PalmOne couldn't make the dynamic heap too big...

OK, I respect Robert as a very talented developer and take his analysis of the T5's memory partitioning at face value. He has not made the mistake I'm about to point out, but almost everyone who posted after him has.

Let's think about this for a second. If the T5 has 12 MB of SDRAM for program execution, that's a huge amount because that's all that memory ever does--it's ALWAYS free in between program executions. How many folks have 12 MB free RAM on their PDAs? On a 16 MB PDA like the Sony T665C, that 16 MB must hold programs AND have enough left to run programs. We've all encountered times when our RAM filled up with apps and their data and we couldn't load a large database from a dictionary or some other reference. By this analysis, that will never happen on a T5 because it will always have 12 MB free SDRAM! The apps that would occupy the RAM on a T665C or TE or any other device will be in the 63.8 MB of FlashRAM, not the SDRAM.

Thus the proper analogy is that the T5 has the equivalent of 12 MB + 63.8 MB = 75.8 MB of user-available RAM compared to other devices, not 12 MB. You can argue about the type of memory and its merits, but the amount isn't in question.

I have no intention of buying a T5, as I'm very happy with my T3. However, I feel compelled to offer some clear thinking in the midst of all this emotion, not in Robert's post but in many that followed. It's just a piece of plastic and metal, not a religion.

[jjesusfreak01]

Let's think about this for a second. If the T5 has 12 MB of SDRAM for program execution, that's a huge amount because that's all that memory ever does--it's ALWAYS free in between program executions. How many folks have 12 MB free RAM on their PDAs? On a 16 MB PDA like the Sony T665C, that 16 MB must hold programs AND have enough left to run programs. We've all encountered times when our RAM filled up with apps and their data and we couldn't load a large database from a dictionary or some other reference. By this analysis, that will never happen on a T5 because it will always have 12 MB free SDRAM! The apps that would occupy the RAM on a T665C or TE or any other device will be in the 63.8 MB of FlashRAM, not the SDRAM.

I'm no expert, and this is a question, but I thought that heap memory was what really mattered when opening up large files or web-pages within a program. I understand how 12mb of memory is alot just to run a program, but does it really mean anything if there isnt enough heap memory, to open big files?

[FullAction]

Re Zodiac:
You are correct, I have never handled one and that's why I wrote "seems bulky". If it is available in local shops, I will gladly try it, handle it and buy it, if it suits my needs and is as suitable for non gaming purposes as you say.

Re Memory:
You are correct that 12 MB are enough for most Palm programs, and the amount is not the problem IMO, but the speed, with which the contents of this memory have to be transferred back to flash is concerning. Already the reduced heap space makes problems for some programs and others refuse to run at all. Will all these necessary updates be free? I think not, because a lot of work will have to be put into the changes. Some developers might even abandon the plattform, if it's too elaborate to do.
A piece of electronics is not even near a religion for me, and if the majority of Palm users is fully satisfied with the new configuration, more power to them. I only see this as a half baked attempt to shine in wrong features, because the interesting features are too complicated or expensive to implement.

[tanker_bob]

From PalmSource's Developer's website:

The Palm OS divides the total available RAM store into two logical areas: dynamic heaps and the storage heaps. A process's dynamic heap is used as working space for temporary allocations, and is analogous to the RAM installed in a typical desktop system. RAM not reserved for dynamic use is designated for the storage heaps and is analogous to disk storage on a typical desktop system.

Because power is always applied to the memory system, the dynamic and storage heaps preserve their contents when the handheld is turned "off" (that is, when it is in low-power sleep mode). Storage heaps are preserved even when the handheld is explicitly reset (unless the user performs a hard reset, in which case the storage heaps are reinitialized).

The Dynamic Heaps ^TOP^
The dynamic heap provides memory for dynamic allocations. From this heap the system provides memory for dynamic data such as global variables, system dynamic allocations, application stacks, temporary memory allocations, and application dynamic allocations (such as those performed when the application calls malloc() or MemHandleNew()). Each process has an independent dynamic heap that is created and destroyed along with the process.

The entire amount of RAM reserved for the dynamic heaps is always dedicated to this use, regardless of whether it is actually used for allocations. The size of the dynamic area of RAM on a particular handheld varies according to the OS version running, the amount of physical RAM available, the requirements of pre-installed software such as the TCP/IP stack or IrDA stack, and any other licensee requirements.

The Storage Heaps ^TOP^
The remaining portion of RAM not dedicated to use by the dynamic heaps is configured as a set of storage heaps and is used to hold nonvolatile user data such as appointments, to do lists, memos, address lists, and so on. An application accesses a storage heap by calling Data Manager functions such as DmNewHandle(). Storage heaps retain their contents through soft reset cycles.

The size of the storage heap available on a particular handheld varies according to the OS version that is running; the amount of physical RAM and ROM that is available; and the storage requirements of end-user application software such as the Address Book, Date Book, or third-party applications.

Well-written programs shouldn't have a problem with a 4 MB dynamic heap. Earlier Palm OS versions have only had about 256K of dynamic heap. Perhaps Robert can offer a practical perspective.

[Sleuth255]

As I alluded to in Gekko's T5 thread, now we know what P1 is doing and why. They are becoming a smartphone company. They've dropped PDA's. The T5 is obviously cobbled together from the TE2 project and injected with the Treo RAM development project. They slapped us in the face when they priced it at $399. NAND technology is great in a smartphone but useless for a PDA. There may well never be another P1 branded handheld.

[ricardocf]

161.2 MB - Internal VFS-like storage area
63.8 MB - User program store (where apps are normally stored)
31 MB - OS system image

If we add 161.2 + 63.8 + 31 that gives us 256. I do not see where the 16 MB come from. Are we saying those 16MB of SRAM are a subset of the 31MB for system image? or are qe just making up the 16MB out of nowhere?

[WuWei]

How many folks have 12 MB free RAM on their PDAs?
I have 40 Mb free on my T3 right now, and I have never run out of memory. That's the advantage of buying a unit which has 64 meg of RAM.
Thus the proper analogy is that the T5 has the equivalent of 12 MB + 63.8 MB = 75.8 MB of user-available RAM compared to other devices, not 12 MB.
Well, I have a 256 Mb SD card, so would people say that I have the equivalent of 64 +256 = 320 Mb of user-available RAM on my system? Because what happens is that the OS loads the applications from the SD card temporarily into RAM, runs the application, then deletes it from RAM, so that the RAM is then available for the next app.
The reality is that people will only say I have 64 Meg of RAM, because running from SD card is much slower than running directly from RAM. That's what it comes down to is performance not religion. The benchmarks and real world experience posted here show that the T5 is slower than the T3, and that's one reason I won't buy a T5.

[winexprt]

The T5 essentially has only 16 MB of real, static RAM.


When put like that, $400 seems an OBSCENE price for this PDA. ESPECIALLY when you factor in lack of built-in WiFi.

My $299 WiFi enabled, High-Res+ screen TH55 that I bought BRAND NEW, is looking more & more like the last great Palm OS PDA that it was. :) Even MORE so considering it came with 32MB Ram. ;)

[winexprt]

It will be available in the UK next week on 10/22, and expanding throughout Europe soon.
That's taking this OT, but I'd have to respectfully disagree. Unless you have actually seen the Zodiac in person and handled one, you should reserve judgement ;). I had the same reservations before I actually saw and handled the Zodiac in person, but I was suprised at how thin and sleek it actually is considering it's official dimensions.
I've heard the business meeting argument about the "console-like" appearance before, and again I'd have to disagree. With the muted gray or black finish, it's very subdued and doesn't attract any stares from co-workers. Compared to the bright blue Zire 31/71/72, the Zodiac is quite conservative in appearance. I'm aware of quite a few owners that work in corporate environments, and I have shown my Zodiac 2 to several other "suits", and none of them have ever complained about strange looks or remarks due to the Zodiac's appearance in a business meeting. BTW, the Zodiac has silent/vibrating alarms, something the "corporate" T5 does not. Having a T5's audible alarm go off in one of those meetings would be much more embarrassing than taking out a subdued, metal-bodied Zodiac PDA.
Brian


EXCELLENT rebuttal! :)

I too was of the ilk that the Tapwave was this giant beast. When I actually saw one in person and held one in my hands I was VERY pleasantly surprised to say the LEAST. It had a very "Clie like" stlye & elegance to it...even sleek I would say. It was MUCH smaller and compact, and elegant than I ever imagined. It is truly a sweet little device. If the Tapwave Zodiac had built-in WiFi (it may very well do...shows you how uninformed on the TW I am ;) ) I would SERIOUSLY consider it for a replacement for my TH55, as NOTHING palm is producing currently, or HAS produced since 1998 has been worth my money. Sony RULED for me. Since they're gone and it really doesn't look like they're coming back, I want to stay with the palm os I know & love so well. Tapwave may very well be my next PDA. :)

That being said, I wish the Tapwave was more well known than it is...to the GP at least. Most people think of either Palm or Sony Clie's when they think of palmOS devices. And with Sony gone, and palm putting out what, and I'll be kind here, can only be described as 'dissapointing' devices lately...we need every innovative device we can find.

[SoS]

Tanker_bob...the voice of reason as ever!!

one thing though, seems to me that 4Mb dynamic heap maybe too little for some of the more demanding apps such as games and such like. I know warfare inc etc wont run on my TT (ok, only 800K heap) but 4mb seems a bit limiting in this day and age.

[palmato]

Thus the proper analogy is that the T5 has the equivalent of 12 MB + 63.8 MB = 75.8 MB of user-available RAM compared to other devices, not 12 MB. You can argue about the type of memory and its merits, but the amount isn't in question.
Sorry but that sum makes no sense. The system ram (as opposed to the flash ram) mainly acts as a mere cache and you cannot simply add it to the rest. 4M of system ram goes to the dynamic heap which handles temporary memory allocations and the stack. The other 12 Mb are used to run programs and access data located in the flash ram. And run the OS too.
It's important to understand that no direct access to flash memory is possible without going through that bottleneck.
12MBytes is not a huge amount of memory and while PalmOS programs are usually a lot smaller, it still can cause considerable slowdowns if applications are not carefully optimized or need to access a lot of data. In comparison a pure 64MB SDRAM implementation will always be faster.

[tanker_bob]

Sorry but that sum makes no sense. The system ram (as opposed to the flash ram) mainly acts as a mere cache and you cannot simply add it to the rest. 4M of system ram goes to the dynamic heap which handles temporary memory allocations and the stack. The other 12 Mb are used to run programs and access data located in the flash ram. And run the OS too.
It's important to understand that no direct access to flash memory is possible without going through that bottleneck.
12MBytes is not a huge amount of memory and while PalmOS programs are usually a lot smaller, it still can cause considerable slowdowns if applications are not carefully optimized or need to access a lot of data. In comparison a pure 64MB SDRAM implementation will always be faster.
I wasn't making a point about speed, but I think that you misunderstand how Palm RAM is subdivided and used. I recommend carefully reading the extract from PalmSource's Developer's info that I posted earlier. The 12 MB SDRAM on the T5 is every bit like what you call "system RAM" on any other device except in one sense--you can't fill it up by manually stuffing apps and data into it. It is basically the storage heap described above. The 64 MB of FlashRAM acts just like the OS Flash area in every other device with Flash (with some happy exceptions) when you use JackFlash in the respect that you can't run apps directly from it. Apps must first be copied to the storage heap (SDRAM) to execute. Unlike JackFlash, though, the T5 also copies the appropriate data files as well. My bottom line is that the 12 MB of storage heap is ALWAYS available. I don't know of any Palm OS app that remotely comes close to that size. So, unlike any other Palm OS PDA, unless you come up with a 12 MB app, the T5 will theoretically NEVER run out of usable storage heap to execute a user's apps. In essence, it's like free memory above and beyond anything any Palm OS device had before. PalmOne doesn't even count it in the device's specs as far as I can tell.

Overall, the ~64MB of FlashRAM is highly analogous to the storage heap in every other Palm OS device. The user may pack it full of apps and data that will be readily accessible. Two major differences come to mind: 1) you can fill it to the brim without sacrificing your ability to execute any app with a large database, something you cannot do on any other device; and 2) the OS must go through the extra step of copying the app and its data to the SDRAM to execute and the data back again at termination. However, this copying process is very fast compared with an external card. Those of us who've used JackSprat/JackFlash have been doing the out-copying for years and were thrilled to have the flexibility. It's interesting to me that what was a highly desired capability a month ago is suddenly a disaster in some folks' eyes.

The 160 MB internal drive is set up completely differently. The analogy there is to an external memory card, only much faster. The advantage is that it is always with you, whereas a card may not be. With only one SD slot, you can have your WiFi card in for example, and still have access to photos, MP3s, and other data on the internal drive--like having two SD slots in many ways. That point seems to have been lost in this debate as well.

Is it a slower system with the FlashRAM? Sure, under some circumstances, but it's probably not noticable under average use (the Find function being one noteable exception). I've never noticed a difference loading apps under JackFlash even on slower 20 MHz Palms. But slower access doesn't mean that it's a 16 MB device. My point is simply that all this hoopla about the AMOUNT of memory is incorrect, probably because most people don't understand how the Palm OS uses memory. Speed of access is a different issue, but every design involves trade-offs. No free lunch, eh?

[FullAction]

Sorry, but there's flaw in your argumentation. While it's true that no Palm programm is in itself 12MB large, it doesn't mean that it couldn't need as much ram or even more. ScummVM is one example, but I'm sure there will be others.
It's also a different scenario, if only the applications are located in the flash or also the databases. You compare the usage of the flash to the built in flash of former Palms. On these machines the databases are still in the ram, so editing data records does not lead to a stall of the OS. It's already been reported that background mp3 listening stutters more on the T5, than e.g. the T3, so stalls are obviously inevitable.
What we have here is basically a 16MB Palm with a 256 MB flash card and an intelligent flash-to-ram-and-back copying mechanism like PowerRun or ZLauncher built into the OS. So apart from the faster cpu and the Hires+ screen, we are where we were 2-3 years ago technologywise.

EDIT:
Actually nobody was asking for this feature, so why should I have to trade off speed for nonvolatile memory? If I wanted sluggish performance on a PDA, I would have bought a PPC.

[tanker_bob]

So being that hardly anyone has 12 MB of free storage heap now, you're saying that memory-hog programs like ScummVM don't run on the overwhelming majority of Palm PDAs now? And that's PalmOne's problem why? Even my T3 has only about 6 MB free storage heap right now.

If the 416 MHz T5 can't play MP3s in the background w/o stuttering when 33 MHz Sony T615Cs could off a much slower memory stick, I submit that the problem isn't the memory scheme.

VFS flash cards have a fundamentally different API with more overhead than the T5's 64 MB of FlashRAM. The real flaw in my argument appears to be that I'm not oversimplifying to make a point. Sorry, can't help you there.

Feel free to believe what you wish. I was just trying to infuse some hard, verifiable data into the emotional fray.

[SoS]

Bob,

isnt it the small dynamic heap stack size that may cause problems??

[FullAction]

Well, I'm not oversimplifying, but it's just a fact that 4MB is less than 11MB. If only memory hog programs will need that extra heap now is completely irrelevant. Software evolves and with progress it usually needs more resources not less. Your argument reminds me of Gates famous quote, that 640kB are enough for anything.

If this is Palm1's problem or not is to be detemined. If buyers are put off by the trade in speed for elusive safety, then it will become Palm1's problem. It certainly isn't mine.

[Bobbert]

...nobody was asking for this feature, so why...I've seen this argument a few times by people frustrated with NAND memory because of the problems it's causing. Especially related to "keeps information even when batteries run down".

I think it's not for consumers, but intended for corporate clients. Thus the implementation of Blackberry that's comming also to the Palm world. I think there's a lot of money up for grabs in the corporate world, and PalmOne/PalmSource is going to need to have a piece of the pie to survive. My guess is that "jump drive in a Palm" and "don't lose data if battery goes dead" are a BIG deal for corporate buyers.

But following the original sentiment, I think that bottom line the corporate users are actually going to benefit from some of the same things that use consumer types like. The marketing gab only goes so far, especially in the corporate world.

[GadgetGuru]

With regards to 'Jumpdrive" I don't think it's too hot in a corporate setting. In fact, Microsoft is trying to disable such a feature in Longhorn. These kinds of drives are a security risks, not just that it could easily introduce viruses and trojans to the network, but it ould be used to steal corporate secrets/data (ie industrial espionage). As to data that never forgets, it both a boon and a bane, data that never forgets even if discarded/lost are security risk, just as harddrives that are not full cleaned/properly overwritten before disposal...

[palmato]

I wasn't making a point about speed, but I think that you misunderstand how Palm RAM is subdivided and used. I recommend carefully reading the extract from PalmSource's Developer's info that I posted earlier.
.....
But slower access doesn't mean that it's a 16 MB device. My point is simply that all this hoopla about the AMOUNT of memory is incorrect, probably because most people don't understand how the Palm OS uses memory. Speed of access is a different issue, but every design involves trade-offs. No free lunch, eh?
Sorry but there's basic misunderstanding here. I'm talking about how hardware is built not what the OS presents to the programmer / user.


The T5 has only one main ram: there's no physical difference anymore between storage heap, rom or the new internal drive. Everything lies in the same chip, a 256 MByte flash ram managed by a special controller (see m-systems links published in another thread).
This memory is partitioned in three areas: one holds the OS image, one the storage heap and one the so called internal drive. The term partition is not randomly chosen: in fact DiskOnDrive requires these to be formatted with a FAT like file system. This is a very elegant design, but more on this later.
Now the problem is that you cannot execute any code directly on 256Mbyte flash chip. You need to have something in between, such as the so called (16MB) system ram. This is where all code must be transferred to in order to be executed. This includes the OS, the programs and the databases. Of course all of this is not transferred in a single chunk, but rather in smaller blocks as they are needed. Again: OS, storage heap and internal drive all share the same mechanism.


Now, if an application needs a lot of data and code, the transfer from flash to ram might not be able to keep up. In the worst situation, the so called thrashing can occur and the system can be brought down to its knees. It's not just a matter of speed, also stability may be compromised.


Now don't get me wrong. I like this design a lot. It's very elegant and yes it has something to do with the zen of Palm. It makes the design of different devices a lot simpler since it scales very well. Need a palm with 512M? Just upgrade the flash chip. Need to have more storage heap as opposed to internal drive? Repartition the flash. All of this without going through a tedious "redesign of the wheel" process. After all Palm1 is not totally dumb. Having this design shared between all devices will make the overall production process more efficient and cheaper.


That however requires applications to be carefully optimized. There will be lots of issues and crashes. And in some cases the device may perform as 8MB device.
But eventually, if all of these problems are fixed then this design might be an excellent idea.


Note: Programs that already deal with an external cards have an advantage here, because they already know their storage is slow and are already optimized.

[Antoine]

Palmato, thanks for the excellent and comprehensive explaination. From what you say, and the issues that have been had with the T5, it seems that programs just have to be written with this new RAM feature in mind. Maybe the case is that P1 hasnt had the time to really optimize this new RAM with features. If your explaination, and Ben Combee's as well, are saying what I think they are saying, Cobalt will be extremely nice with the RAM, and may even make the PalmOS as good as a desktop for many more people than just us PDA lovers.

[GadgetGuru]

if all of these problems are fixed then this design might be an excellent idea.

Great, except why are end-buyers being used to beta test (sort of) their idea. They should crash test them, not end-users. Trying to steal a page from Microsoft's playbook?

[tanker_bob]

Bob,
isnt it the small dynamic heap stack size that may cause problems??
I guess it depends on what a given application requires. The max dynamic heap you can set in the Garnet simulator is 2 MB. Here's an programming article from Mobilized Software (http://www.mobilizedsoftware.com/showArticle.jhtml?articleId=20800144) on dynamic heap size:
The tricky part is that the size of the dynamic heap can be quite small when compared to the size of the storage heap. Until Palm OS 5, in fact, the size of the dynamic heap only ranged from 64 KB to 256 KB, depending on the total amount of memory available on the device. You had to resort to using the storage heap (with its slower, more complicated APIs) if your application needed more run-time memory. Newer devices running Palm OS 5 have much higher limits on the size of the dynamic heap. The palmOne Tungsten T3 has a 4 MB dynamic heap, for example, which is a huge increase when compared to 256 KB. These new limits (which vary from device to device) make for much simpler programming, especially for graphics or other memory-intensive tasks. However, if you need to support the majority of devices currently in use (the ones running Palm OS 3 or 4), you'll need to work well with the smaller heap sizes.
Another reference on WebSphere (http://64.233.161.104/search?q=cache:IHtDXvKvW5AJ:pluggedin.palmone.com/regac/reslib/ViewDocument%3Fapp%3Dchsrc%26docId%3D892+palm+dynamic+heap+size&hl=en) actually has a table of OS 5 devices (please excuse the poor formatting):
Device...........Dynamic Heap........Storage Heap
Treo 600............3mb.....................32mb
Tungsten T3.......4mb.....................51mb
Tungsten C.........4mb.................... 51mb
Tungsten E.........1mb.....................32mb
Tungsten T2.......1mb.....................32mb
Zire 71...............1mb.................... 16mb
Tungsten W........1mb.....................16mb
So despite all the complaining, 4 MB seems the same as the T3 and pretty generous to me since pre-OS 5 devices were limited to 256K. Looks like another T5 myth debunked. [rolleyes]
As an interesting sideline, every programming reference I checked pegged the T3 dynamic heap at 4 MB, but almost every product review and general user posts pegged it at 12 MB. If I run SystemAnalyzer on my T3, it comes up with a little over 11 MB of heap, and it's heap 0 which by Palm convention is the dynamic heap. However, 12 MB of dynamic heap doesn't make any sense given the 4 MB limit on other devices. Haven't nailed down the story on this yet, but I will!

[Cyker]

WTF?! You lot have totally lost me now...

Gimme a comparison of numbers with my TH55 or something!
For my TH55, I am fairly certain that it has:

32MB ROM for OS image, not completely used up. (I designate this The ROM)
32MB RAM allocated for Program and Data Storage. (The Internal RAM)
7MB of RAM for program data storage during program execution (The Stack)

And in my case, 512MB of non-volatile FlashROM in the form of an MS Pro. (The VFS)


The data I'm getting from you lot seems to say that the T|5 has:

31MB ROM for the OS Image (The ROM)
0MB RAM allocated for Program and Data Storage. (The Internal RAM)
4 MB RAM for program data storage during program execution (The Stack)

So WTF is this:
12 MB - memory protected database cache area, also where feature memory is allocated (RAM?)
161.2 MB - Internal VFS-like storage area (FlashROM?)
63.8 MB - User program store (where apps are normally stored) (Also FlashROM??)

It sounds quite scary - Like Palm have abandoned the Run-In-Place type of execution and gone for the less efficient but more conventional Load-and-Execute type of execution - This is how I'm interpreting it:

The 161.2 MB (Internal VFS-like storage area) and 63.8 MB (User program store) act like my VFS card, so they are non-volatile RAM, but when you run stuff off them it copies the whole lot into the 12MB 'Database cache' and then executes it from there.

A possible alternative translation in my head is similar to the above, except the 63.8MB store acts more like a Brayder JackFlash'd ROM, where Run-in-Place execution still occurs (Instead of the program being copied into this mysterious 12MB area first), but the OS handles writable files by bunging them in the 12MB store while they're open, and putting them bck after.

Both these explanations seem wrong, because they'd both indicate a *radical* departure from the standard PalmOS structure...

So someone, help me out here!

[slinger]

Here's an programming article from Mobilized Software (http://www.mobilizedsoftware.com/showArticle.jhtml?articleId=20800144) on dynamic heap size:
Another reference on WebSphere (http://64.233.161.104/search?q=cache:IHtDXvKvW5AJ:pluggedin.palmone.com/regac/reslib/ViewDocument%3Fapp%3Dchsrc%26docId%3D892+palm+dynamic+heap+size&hl=en) actually has a table of OS 5 devices (please excuse the poor formatting):
Device...........Dynamic Heap........Storage Heap
Treo 600............3mb.....................32mb
Tungsten T3.......4mb.....................51mb
Tungsten C.........4mb.................... 51mb
Tungsten E.........1mb.....................32mb
Tungsten T2.......1mb.....................32mb
Zire 71...............1mb.................... 16mb
Tungsten W........1mb.....................16mb

I'm not sure where they got these numbers for the T3 and the C as they are completely wrong. Here's more accurate info directly from the PalmOne developer SDK's:

Device...........Dynamic Heap........Storage Heap
Tungsten T3.......11mb.....................52mb
Tungsten C.........12mb.................... 51mb

-Robert Hildinger

[GadgetGuru]

Palmsource should have fixed these dynamic heaps sizes instead of letting OEMs fiddle with it, since they directly affect OS performance, and in turn, the perception of the operating systems.

[slinger]

Well-written programs shouldn't have a problem with a 4 MB dynamic heap. Earlier Palm OS versions have only had about 256K of dynamic heap. Perhaps Robert can offer a practical perspective.
In most cases for existing PalmOS software this is a fair statement, but unfortunately it's only for most cases, not *all* cases. One major case of 4MB being a very limiting factor is with web browsers. I can remember when the first WiFi capable Sony Clie's came out that had 4MB dynamic heaps it seemed like all you ever encountered was "Page too large" errors because Netfront couldn't allocate enough memory to render the pages correctly. You couldn't even think about running a web browser with only 256K...

Other cases include emulators where you have no control over the size of the ROM target you're trying to emulate. Power48 has this problem with the emulation of the 49G target. It requires a 2MB chunk just to load the ROM image, and another 1MB hold the RAM. Add to that the memory used up allocating offscreen bitmaps and you begin to realize that sometimes it doesn't matter how well-written a program is, it just needs a lot of RAM to do its thing. Generalizing about the efficiency of the code becomes a moot point.

In almost every case, the need for more and more memory is necessitated by the performance perception of the user. As things progress and we begin to handle larger and larger data sets (i.e. map files, emulator ROMs, web page renders, commercial databases, etc...) on our handhelds, the need to be able to access these data elements quickly without resorting to paging or other memory tricks will become more and more crucial.

Alas, it's only my opinion...

-Robert Hildinger

[foghead]

Cyker -
The best way to think of this memory architecture without getting technical is to look at it like the secondary cache on your PC. This is a hunk of high-speed memory and is where the CPU actually executes code from. As the CPU needs data it is copied from the huge system RAM to the cache and executed or used (if it is data). It is generally kept in the cache for awhile in case it is needed again. As space is required, chunks of memory in the cache that haven't been used for a while are overwritten with new chunks that the CPU needs now.

If the cache can't be filled fast enough, the CPU stalls - that is, it just sits there until the code that it needs to execute is in the cache.

This is the concern with the T5 - can the 4 MB execution space keep up with the CPU demands for code and data when the app is actually using more than 4 MB (like the system wide search).

The other point is that if programmers are aware that this is going to be a feature of many different Palm OS devices in the future, they can make their apps a little more friendly by writing apps in ways that will help the system to make the right code available to the processor in a timely manner.

Comparing the RAM in the T5 to L2 cache on a desktop computer is not completely valid, but it should be close enough to give you a good understanding of what is going on and hopefully the people that do understand the issues will forgive my generalities. :p

[slinger]

One thing I wanted to point out after all this discussion is that if you read this thread and begin to think that it has familiar ring to it, you're probably right. What PalmOne has essentially done has provide a virtual memory facility analogous to the VM facilities in most modern OS's. In my initial opening post for this thread I even commented that I think this memory architecture is very well suited to smartphones which by their nature are often limited in their ability to power large amounts of static RAM.

I find it interesting to note however that virtual memory is not the panacea that the OS vendors hoped it would be. Sure you can run Windows XP in as little as 128 MB with virtual memory, but if you actually want to do anything useful with it you stuff your PC with as much memory as it can handle. It's not uncommon to see PC's today with 4GB of main RAM and the VM system totally disabled. The mantra of the tech support department of every game developer seems to be "Add more RAM" when asked about fine-tuning performance. Any high-end resource intensive task on a PC is usually critically debilitated by extensive VM use, causing OS vendors to recommend that VM settings be set to very low ratios of physical to virtual memory to avoid huge performance bottlenecks.

My question then is, how long before these same problems come up in PalmOne's VM implementation? Believe me, they will sooner or later...

-Robert Hildinger

[SoS]

Hi again Tanker_Bob,

the websphere site also claims that the tungsten T is not supported because it has a small dynamic heap, the T2 is supported. This is fine, except that the T2 has the same dynamic heap as the T AFAIK, both ~1Mb...

Have P1 claimed anywhere that the T5 has 16Mb dynamic heap?? If so, they really need to clarify!!

[Cyker]

Cyker -
The best way to think of this memory architecture without getting technical is to look at it like the secondary cache on your PC. This is a hunk of high-speed memory and is where the CPU actually executes code from. As the CPU needs data it is copied from the huge system RAM to the cache and executed or used (if it is data). It is generally kept in the cache for awhile in case it is needed again. As space is required, chunks of memory in the cache that haven't been used for a while are overwritten with new chunks that the CPU needs now.
If the cache can't be filled fast enough, the CPU stalls - that is, it just sits there until the code that it needs to execute is in the cache.
This is the concern with the T5 - can the 4 MB execution space keep up with the CPU demands for code and data when the app is actually using more than 4 MB (like the system wide search).
The other point is that if programmers are aware that this is going to be a feature of many different Palm OS devices in the future, they can make their apps a little more friendly by writing apps in ways that will help the system to make the right code available to the processor in a timely manner.
Comparing the RAM in the T5 to L2 cache on a desktop computer is not completely valid, but it should be close enough to give you a good understanding of what is going on and hopefully the people that do understand the issues will forgive my generalities. :p
Waa, this is confusing me even more!!

Deep breath... re-read...

Righty, I think your description if going too far out of context for what I'm asking...

Assume that I understand standard Mac/PC/Amiga/Atari/C64/etc. Load-and-Execute style architecture, and that I understand Palm's Run-In-Place architecture.


From what I've been able to figure out, the T|5 works like my second theory - i.e. the 64MB of storage, which would be the volatile internal RAM in a T|3, is now a FlashROM which works in the same way as a Brayder JackFlash'd FlashROM, but slightly different in that the OS has extra hacks to let it pull to-be-modified data out into this mysterious 16MB area, modify it, then write it back to the FlashROM when the program closes that data.

If this is the case, I can imagine some real nasty incompatibility problems cropping up if their code isn't 100% watertight...
It's a good idea 'tho, but I would have preferred this 64MB of JackFlash-style ROM *in addition* to the Internal RAM...

It's also gonna be a complete ***** for running programs off VFS because that means instead of copying the program into Internal RAM, it will have to copy it into this 16MB area and allocate all it's data-space from there too if I understand this write! (Unless running VFS stuff copies the program into the 64MB FlashROM...)

If all these thoughts of mine are what the T|5 actually is (I still can't get a clear answer!!), then I have a feeling heavy use will kill a T|5 really fast - Flash has a *much* lower life cycle than normal DRAM, and given how fast some people here have killed their VFS cards with repeated writing, then things like frequently modifying Memos, Todos, databases et al will drain those FlashROM write-cycles in no time!!!

[WuWei]

One piece of good news is that the chip that controls the flash memory in the T5 spreads the writing evenly over the entire flash. That should greatly extend the total lifespan of the flash.

For example, if I modify the same memo 100 times, the flash controller chip might write each copy to a different part of the flash, so that each one is only written one time instead of writing to the same part of the flash 100 times.

[foghead]

Actually, the life cycle isn't anything that you should be concerned about. It has always been overemphasized and it is less of a problem now than ever.

The flash in the T5 is good for over 100,000 writes per block (location). This is probably more than will be done in the life of the device because even if you change data while an app is running, it is only written back out when the app is terminated. There may also be some timed writeback, but I don't know (don't even really care). If you were to change a data location every ten minutes, twenty-four hours a day, 7 days a week, 52 weeks per year, it would take two years to just wear out that single location.

Wearing out a single location isn't even a concern because the flash also has write balancing built-in. This means that as data is written to the flash chip, it is always written to the locationson the chip that have been written the fewest times. This way you get the life of the entire memory chip rather than worrying that some areas might be getting maxed out by constant changes.

[Cyker]

Man that sucks, my MSPro is only rated for ~20,000 cycles!!!

But if it really is 100k-cycle Flash, and that other post about the whole Flash chip being used then you are right - the device will obsoless long before the Flash dies! :)