Results 1 to 10 of 10
  1.    #1  
    PalmOne will not be able to change the 512 byte storage units in the NAND chip with a ROM update. The 512 byte storage is part of M-sys's filesystem (TrueFFS). The PalmOS sits it own File System on top of TrueFFS. TrueFFS is a middleware between the PalmOS and the NAND chip providing a driver for the PalmOS to use the TrueFFS. TrueFFS has drivers for all of the major operating systems. The M-sys tech doc is linked below:

    M-sys DiskOnChip

    Based on this information, the only way I can see that Palm can fix the 650 in its existing form with the 32 MB NAND chip is to totally rewrite the PIM applications to create larger, single record databases that would actually put all of the individual records into one contiguous record. This would minimize the effect of the 512 byte storage chunks used by TrueFFS. I don't see this as being an easy fix for Palm to accomplish. I also don't see this as an optimal fix as I think it would slow the accessing of data in the database.

    I thought I would put this out as I have seen a lot of people making a lot of hopeful comments about a yet undeveloped ROM update that is going to miraculously fix the way the NAND stores data. Unless M-sys were to make a change in their TrueFFS just for Palm, this is not going to happen. I have a serious feeling that their will be no ROM update coming to "fix" this for the following reasons:

    - The 650 is the only device with the issue right now.

    - NAND storage functionallity is not in PalmOne's direct control.

    - PalmOne probably has all OS development resources working on Cobalt, and not on the existing OS or applications. Taking resources to work on this problem will delay Cobalt that much more.

    - It would be more cost efficient for PalmOne to create a running change on future 650's that would just have a 48 MB or 64 MB NAND chip and not to put development costs to work around a memory storage issue. A larger NAND chip would require minimal re-engineering since all of the drivers and applications are there. End result would be either 39MB or 55MB of application storage depending on whether they went with a 48 or 64 MB NAND respectively.

    PalmOne could surprise everyone, but the more technical information that I read on the NAND from the developer's own sites, it is looking pretty grim for the early adopters who have memory issues.

    Now before the flaming begins from all of the PalmOne defenders, look over the M-sys document, and the PalmOne document that is linked on the TC home page. If you look at the documentation and disagree with me, then by all means lets have a civilized discussion in this thread on why you think I am wrong in my assumptions or interpretation of the data. I was one of the first 600 users getting mine in October of 03, I love the device and it has served me well. I like the PalmOS. I know that I am unlikely to be truely affected by the memory issues, but I also feel that PalmOne is not addressing the issues of the 650 properly, and may in fact be providing false hope to the early adopters to do a CYA.
  2. alee's Avatar
    Posts
    410 Posts
    Global Posts
    805 Global Posts
    #2  
    My guess is this is probably more simply accomplished by changing the PIM data structures to better fit 512 byte segments. This would mean either using compression, or writing multiple records per block and having some sort of system to manage this.

    How I'd approach it:

    If each record is typically 14 bytes, they could fit 36 records into 1 block. Then they would need a table which says "if record #12 is being called, address block 1", "if record #42 is called, call block 2". Since the OS reads in in 512 blocks regardless, there is no peformance hit there. The penalty is if you write to a block, you have to read in a set of 36 record, change a record within those 36 records, and write it back. I think there will be more of a performance hit there.
  3. #3  
    Quote Originally Posted by lnichols
    Based on this information, the only way I can see that Palm can fix the 650 in its existing form with the 32 MB NAND chip is to totally rewrite the PIM applications to create larger, single record databases that would actually put all of the individual records into one contiguous record. This would minimize the effect of the 512 byte storage chunks used by TrueFFS. I don't see this as being an easy fix for Palm to accomplish. I also don't see this as an optimal fix as I think it would slow the accessing of data in the database.
    I believe that is precisely the fix that PalmOne expects to implement if any. I don't know if they have to do it for all their applications or just the contacts application. I have over 1100 e-mails and they take up something like 2MBs. Obviously they are able to store e-mail in an efficient way. I don't believe it's nearly as hard to rewrite the contacts application as you have stated. Though I agree it will run slower, the faster processor should be more than enough.

    I agree that the easiest fix might be to go with 64MB going forward, but let's just assume that they bought their 32MB chips in bulk and they aren't going to be able just trade them in so simply. That's very likely the case.

    For what it's worth the T5 has the same issue, but it just has what is considered plenty of memory. We all know that it's plenty of memory for today's applications, but who knows about tomorrow's.

    Personally I think they should also find a way to give out zlauncher or something that makes application run off of the card more intuitive to the end user.
  4. #4  
    They could write a "defrag" program... Couldn't they?
  5. #5  
    They could rewrite the part that hooks PalmOS's filesystem into TrueFFS. If they could rewrite the PIM apps to fit all the data into one continuous record, why couldn't they just rewrite that part to store more than one record per 512 byte chunk instead? It would make sense because it would affect all apps, not just theirs, and it wouldn't be throwing away the whole design concept of records.

    As for Cobalt, either it has the same problem, and thus this is worth solving, or it was already dealt with, and thus they at least have some headway into solving it on OS 5.
  6. #6  
    In the end, how DID they fix this?
  7. #7  
    Ah, a blast from the past. Next time believe the programmers (like me!) when they tell you these are solvable problems.

    According to this article, they did what we said they would, which is to divide up each 512 byte block into smaller blocks. It takes a little behind-the-scenes work since the card works natively in 512 byte blocks, but it's easily feasible to work in the smaller 32 byte blocks instead.

    If you need a subblock, you read the block and extract it. To save a subblock, you read the block, change the subblock, and write the block back. There's definitely caching and such going on to make this more efficient (i.e. combining multiple subblock writes in memory so it only writes the block to flash once) but that's the general idea.
  8. #8  
    I don't remember where I saw it but some time ago I read that it was dealt with pretty much as Alee has described above in post #2.
  9. #9  
    I don't think they did what post #2 said, since it wasn't just the PIM programs that benefited, but all programs. I think GregV's got the right idea.
  10. #10  
    ericfairchild, you are right. It was not a PIM specific fix, it applied to the NAND in general. The second part of alee's post describes something quite similar to GregV's in that it has a method to read and write smaller blocks within the main blocks. That is the part I was referring to and I should have stated that clearly.

Posting Permissions