Page 2 of 2 FirstFirst 12
Results 21 to 26 of 26
  1. #21  
    Quote Originally Posted by lnichols
    This is not a PalmSource issue based on my understanding from what I have read. This is a NAND functionallity issue.
    I suppose it's true (i.e. it's a limit from the NAND chip), but it could also be a PalmSource decision to use 512 bytes instead of 256 or 1024, I don't know enough to find out where the truth is. Anyway, it's most probably not PalmOne's fault if there's this 512 bytes sector limit when using NAND Flash. But it's clearly PalmOne's fault not to have mentioned this somewhere in its docs and ads, as it affects the end users, who is not supposed to query PalmSource for such technical informations, is it?

    Palmsource is simply storing data like they have always done but the byte boundary used to be 14 bytes with the old method. So now a record that would have only taken 14 bytes will now take 512 bytes.
    I think the 14 bytes figure comes from my initial post on this subject last week, but it was just an example, not a "cluster" size. Actually, when you add a database to the PalmOS RAM, each and every record is stored in its individual memory chunk. There's no boundary limit (except that the memory address must be even, so at most you'd add one byte to a record or resource which size is an odd number), but a header (8 bytes) is added in front of each memory chunk, and there's an additional entry in the database list (4 bytes), so adding a one byte record in a database would cost 14 bytes of memory, adding a 10 bytes record would cost 22 bytes of memory, etc.

    A simple solution would be to create a single database for all the PIM functions that would grow in size as you added records, then the 512 bytes wouldn't be a houge issue because each entry wouldn't add 512 bytes, it would only increase the size of the total database which may or may not have up to 512 bytes of "pad" for the last part of the database. This would require a complete re-write of the PIM applications.
    There is already a single database (well, sort of, with the new PIM apps everything gets duplicated, but that's another story) for the PIM applications. The problem is that any new agenda or address entry is stored as a new record in the database. The solution would be to aggregate multiple entries in a single record so that you don't need one record (hence 512 bytes at least) per entry. But I agree with you, the PIM apps would need to be re-written completely. And also, doing that would cost more processing power when adding, editing, deleting or searching an entry, since the whole (big) record would need to be read/written each time. This would prevent developers to use the PalmOS database manager that makes using databases so straightforward. Basically, developers would have to stop using the PalmOS database format, which IMHO would be a huge loss!

    PalmOne is selling a device using the PalmSource OS, so in the end, they are responsible for making sure it all works to the consumer.
    Actually, it probably works for most "average" users, except us power users... <sigh>
  2. #22  
    I only hope they will take this opportunity and update the launcher/memory code to support "native" execution from an SD-Card. Then they can save some bucks to make the phone as cheap as possible for the carriers, while still supporting everybody with larger memory needs.
  3. #23  
    As a followup to my previous posts, and to try answering the question "who is responsible for this 512 bytes sector choice?", I've had a quick look at the following link: http://www.aleph1.co.uk/yaffs/jffs2_and_nand.html (thanks to gfunkmagic for generously providing the links in this thread). There's a lot of interesting stuff in there, which I'm in no way able to confirm or infirm, but here's an appropriate quote to help answering our question:
    NAND flash is arranged in pages/sectors of 512b and is inherently block structured.
    So I guess this settles up the question for now: PalmSource and PalmOne took what appear to be the most logical decision in keeping the 512 bytes sector size, as it seems this is the "natural" way to handle NAND Flash.

    So maybe moving to NAND Flash wasn't a wise decision (this is a good topic for another thread ), but assuming one uses NAND Flash, this was probably the most efficient way to handle it. I'm sure PalmOne and/or PalmSource can come up with a fix for this problem, but it will without doubt involve more processing power, and then users will start complaining that the Treo 650 CPU should have been more powerful!
  4. #24  
    Quote Originally Posted by Moroner
    I only hope they will take this opportunity and update the launcher/memory code to support "native" execution from an SD-Card. Then they can save some bucks to make the phone as cheap as possible for the carriers, while still supporting everybody with larger memory needs.
    Alas, if NAND Flash memory isn't "XIP", I don't see how an external memory card could be... On the other hand, this is close to what programs like PiDirect II do, so maybe this stuff could be built in the next PalmOS devices?
  5. #25  
    I didn't know about PiDirect, but that is close to what I am looking for, with the OS updated such that it treats internal and external Flash the same. Of course, there would need to be some extra code that could deal with removed SD cards, a kind of hot plug support. Actually, it would be best if the OS stored that extended memory in a file on the card, so that I can still use the rest to transfer files between PCs ;-)
  6.    #26  
    Quote Originally Posted by The Zen of Palm
    I don't think you know what you're talking about. I assume you found an article somewhere on the Internet on NAND Flash (Red-Mercury, perchance?) and are now parrotting what you think it's all about. As it now stands, NVFS is inefficient, but not too horribly slow. The RAM buffer used should be fine for all but a very few applications.. Besides skimping on absolute chip size, Palm made the right compromises needed if they insist on using this crappy memory.
    I did read the article on Red-Mercury, but the analysis I have done on this thread is from PalmOne's own article on this. This link was in the TC article "PalmOne responds to memory concerns". Based on the data that Palm provides in that link, the PIM databases, the ones that should be the most efficient, are now the least efficient, ballooning in size upwards of 400%. Any app that uses a database with a lot of records smaller than 512 bytes is going to suffer this same bloat. Most applications should be fine, but since the PIM apps are going to take up so much space now compared before, their will be less room for you apps.

    Take a look at the article yourself and tell me if I am wrong in my statements Zen and be specific.
Page 2 of 2 FirstFirst 12

Posting Permissions