How to erase a faulty flashbank ? - Hewlett Packard

This is a discussion on How to erase a faulty flashbank ? - Hewlett Packard ; Hello, in flashbank E and F pfree.bin from Thomas Rast reports a 32kB object with a is marked as deleted and has a bad crc. It also reports 127kb free memory for this bank but I can not store any ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 66

Thread: How to erase a faulty flashbank ?

  1. How to erase a faulty flashbank ?

    Hello,

    in flashbank E and F pfree.bin from Thomas Rast reports a 32kB object
    with a is marked as deleted and has a bad crc.
    It also reports 127kb free memory for this bank but I can not store
    any object there which is larger as 95 kB.
    Fman.bin by Claudio Lapilli refuses to jump into bank E and F.

    So, how do I erase or reformat this faulty flashbank so that I can use
    it again ?

    TIA and greetings

    Andreas
    http://www.software49g.gmxhome.de


  2. Re: How to erase a faulty flashbank ?

    On Nov 7, 7:31 am, Andreas Möller
    wrote:
    > Hello,
    >
    > in flashbank E and F pfree.bin from Thomas Rast reports a 32kB object
    > with a is marked as deleted and has a bad crc.
    > It also reports 127kb free memory for this bank but I can not store
    > any object there which is larger as 95 kB.
    > Fman.bin by Claudio Lapilli refuses to jump into bank E and F.
    >
    > So, how do I erase or reformat this faulty flashbank so that I can use
    > it again ?
    >
    > TIA and greetings
    >
    > Andreashttp://www.software49g.gmxhome.de


    Try executing the PINIT command. It shouldn't erase anything you've
    got stored, though making a backup of your calculator first probably
    isn't a bad idea. Better safe than sorry.

    -Dave Britten


  3. Re: How to erase a faulty flashbank ?

    > So, how do I erase or reformat this faulty flashbank so that I can use
    > it again ?


    I had that once and I think I found one of the ROMs that was ~ 2MB in
    size and erases the flash. Installed it, put the correct on back on,
    and everything was fine.

    TW


  4. Re: How to erase a faulty flashbank ?

    Hello Tim,

    do you remember which ROM you used for erasing the flash banks ?

    Aren't all "newer" ROMs around the size of 2 MB ?

    Pinit does not handle this problem.

    Greetings
    Andreas


  5. Re: How to erase a faulty flashbank ?

    > Aren't all "newer" ROMs around the size of 2 MB ?

    ftp://ftp-fourier.ujf-grenoble.fr/xcas/hpcas/hp49g.zip

    Grabbing the zip from BPs page, there is a rom file inside that has a
    2mb size. From the readme: "hp49g-u.bin: Will completely erase the
    flash, to be used if user flash got corrupted."

    Give that a try and I bet it will work for you.

    TW



  6. Re: How to erase a faulty flashbank ?

    On Nov 7, 7:31 am, Andreas Möller
    wrote:

    > Fman.bin by Claudio Lapilli refuses to jump into bank E and F.


    I never had a chance to test it with an original 49G (it's tested on a
    49G+ and 50G).
    There's no bank E and F in the newer ARM models, and it seems FMAN is
    detecting that your machine is an ARM model.
    I'll take a look and see if there's a bug there, but I have no way to
    test it.

    Thanks for reporting it.
    Claudio


  7. Does xSTO handles storing in Port 2 properly ?

    Hello Claudio,

    that makes sense ;-)

    An empty 49G reports 1021 kB in the filer, divided by 128 this is
    almost 8 which would be the FlashBanks 8-F.

    An empty 49G+/50G reports 768 kb in the filer, divided by 128 this is
    almost 6 which would be the FlashBanks 8-D. IIRC the 2 Banks are
    needed for the saturn emulation.

    Now talking about storing a large item, a lib with around 120 kB:

    Say, for example, if in all Flashbanks something is stored so that the
    120 kB is not available but the objects in all Flashbanks are small
    enough so that they could be moved to another bank to free a 120 kB in
    a single Flashbank. Does xSTO (given enough RAM of course) handle this
    and moves the objects into annother flashbank trying to free up memory
    like I can manually do with [CUT] and [PASTE] and [PACK] in Fman.bin ?

    I did not find any information about how storing in Port 2 works
    *exactly* and the reported number by xPVARS or the Filer is
    misleading. It happens quite often to me that I try to store a large
    object and it seems that there is enough memory but actually there is
    not.

    Memory management of Port 2 is not very transparent and far away from
    an optimized way ...
    Trying to hide the limitations of the system to the user leads to
    quite some surprising and incomprehensible results and even more
    confusion instead of easing the use.
    At least a single access method for system RPL is desirable instead of
    needing to dive into ML for storing into Port 2. That´s what operating
    systems are there for ...

    > There's no bank E and F in the newer ARM models, and it seems FMAN

    is
    > detecting that your machine is an ARM model.


    E and F is only shown in the top row of the screen. But in contrast to
    pfree.bin the cursors does not move to this banks, same with ERAM 2
    which is used by the ARM models as well.
    So it works quite well on a 49G+ but I got confused by the content of
    bank E and F as pfree.bin (as the ancestor of Fman.bin) behaves
    different this way

    Greetings
    Andreas
    http://www.software49g.gmxhome.de



  8. Re: Does xSTO handles storing in Port 2 properly ?

    So basically...
    you need a flash garbage collector ?

    :-)

    --
    Mario Lohajner (aka manjo)
    Programmer
    manjo@greenvector.com



  9. Re: Does xSTO handles storing in Port 2 properly ?

    > So basically...
    > you need a flash garbage collector ?



    Note :
    garbage collector/defragmenter :-)



  10. Re: Does xSTO handles storing in Port 2 properly ?

    Hello Manjo,

    > So basically...
    > you need a flash garbage collector ?


    Yup, but one that is integrated into the system (as I would expect
    xSTO). I do not want to re-invent the wheel.

    Port 2 looks to me as it is still under construction ;-)

    Greetings
    Andreas



  11. Re: Does xSTO handles storing in Port 2 properly ?

    > Yup, but one that is integrated into the system (as I would expect
    > xSTO). I do not want to re-invent the wheel.
    >
    > Port 2 looks to me as it is still under construction ;-)


    Yes, i see what you mean, but then...

    the "sideeffect" of the PORT2 behavior is that
    stored file doesn't change it's address afterwards

    Meaning: once you put your ARM based program to aligned address it is
    capable of runing almost instantly.
    so the behavior is actually wellcome :-)

    If and when somone whould take care to write such garbage
    collector/defragmenter
    care should be taken to keep the files on aligned addresses.

    Actualy:
    the best would be if a new prologue was introduced for variables
    based or containing ARM code.
    These objects would *always* be kept on 32-bit aligned address thus capable
    of running instantly.
    (no need to relocate anything anywhere -capable of immediate execution)

    This will probably be done once it is decided that Saturn is here to stay,
    yet ways to run ARM more natively will be "invented".

    until then... have fun :-)

    ---
    manjo
    http://fly.srk.fer.hr/~manjo/openfire
    | 49G+ | ROM 2.09 | hw serial:CN40213309 | sw serial:CN40701165 |



  12. Re: Does xSTO handles storing in Port 2 properly ?

    On Nov 8, 11:45 am, "manjo" wrote:
    <...>

    > Actualy:
    > the best would be if a new prologue was introduced for variables
    > based or containing ARM code.
    > These objects would *always* be kept on 32-bit aligned address thus capable
    > of running instantly.
    > (no need to relocate anything anywhere -capable of immediate execution)


    It's called ARMCODE object, and it already exists. It can be EVAL'ed
    just like a regular CODE object, it is stored with FIXSTO when you
    store it in flash, and flash bank repacking keeps ARMCODE objects
    properly aligned automatically.

    Your wish will come true soon...

    Claudio


  13. Re: Does xSTO handles storing in Port 2 properly ?

    > It's called ARMCODE object, and it already exists. It can be EVAL'ed
    > just like a regular CODE object, it is stored with FIXSTO when you
    > store it in flash, and flash bank repacking keeps ARMCODE objects
    > properly aligned automatically.
    >
    > Your wish will come true soon...


    Yes, good thinking
    I whish it would work in RAM too :-)

    And while we're at it (if i may)
    I whish if MASD would align the ARM code
    also it should automatically implement ARMSAT to
    address (where it aligned the following arm code to)
    maybe even a new pseudo opcode lik ARMSTART could be introduced
    which would initiate ARM execution at next following aligned address.
    That way it would not mess with Saturn registers just to stare ARM
    execution.
    Thus ARM code would run *truly* seamless within Saturn code or sysRPL.

    -implementing THUMB! would blow my hat off...

    As you can see there is plenty of work to be done,
    Question is: Where do You want to go today ?
    :-)

    --
    manjo
    http://fly.srk.fer.hr/~manjo/openfire
    | 49G+ | ROM 2.09 | hw serial:CN40213309 | sw serial:CN40701165 |



  14. Re: Does xSTO handles storing in Port 2 properly ?

    On Nov 7, 5:19 pm, Andreas Möller
    wrote:
    > Hello Claudio,
    >
    > that makes sense ;-)
    >
    > An empty 49G reports 1021 kB in the filer, divided by 128 this is
    > almost 8 which would be the FlashBanks 8-F.
    >
    > An empty 49G+/50G reports 768 kb in the filer, divided by 128 this is
    > almost 6 which would be the FlashBanks 8-D. IIRC the 2 Banks are
    > needed for the saturn emulation.
    >
    > Now talking about storing a large item, a lib with around 120 kB:
    >
    > Say, for example, if in all Flashbanks something is stored so that the
    > 120 kB is not available but the objects in all Flashbanks are small
    > enough so that they could be moved to another bank to free a 120 kB in
    > a single Flashbank. Does xSTO (given enough RAM of course) handle this
    > and moves the objects into annother flashbank trying to free up memory
    > like I can manually do with [CUT] and [PASTE] and [PACK] in Fman.bin ?


    If STO did all that automatically, then why would I bother writing the
    Flashtools? :-)
    The idea is that when your flash is full of objects, you can manually
    "optimize" which lib goes where, so that you can get the best out of
    it.

    >
    > I did not find any information about how storing in Port 2 works
    > *exactly* and the reported number by xPVARS or the Filer is
    > misleading. It happens quite often to me that I try to store a large
    > object and it seems that there is enough memory but actually there is
    > not.


    The information is not readily available, but basically STO works as
    follows:

    1) Find the bank with smallest free space that can contain the lib. If
    any bank can contain it, then store it.
    2) If no bank can contain the object, then find the bank that has most
    wasted space and PACK it. Then retry storing.

    Banks are 100% independent, no objects are ever 'moved' from one bank
    to another (and that's why you need Flashtools).


    >
    > Memory management of Port 2 is not very transparent and far away from
    > an optimized way ...
    > Trying to hide the limitations of the system to the user leads to
    > quite some surprising and incomprehensible results and even more
    > confusion instead of easing the use.


    But then you would have yet another thing to learn on an already steep
    learning curve.

    > At least a single access method for system RPL is desirable instead of
    > needing to dive into ML for storing into Port 2. That´s what operating
    > systems are there for ...


    That's what STO/RCL is meant for. A single access method.

    >
    > > There's no bank E and F in the newer ARM models, and it seems FMAN

    > is
    > > detecting that your machine is an ARM model.

    >
    > E and F is only shown in the top row of the screen. But in contrast to
    > pfree.bin the cursors does not move to this banks, same with ERAM 2
    > which is used by the ARM models as well.


    Because the old pfree was written long before the ARM models were
    created. It simply shows garbage (and it may crash depending on that
    garbage).


    > So it works quite well on a 49G+ but I got confused by the content of
    > bank E and F as pfree.bin (as the ancestor of Fman.bin) behaves
    > different this way


    OK, so you *were* using an ARM model, and there's no need for me to
    try and find a bug, right?

    Claudio


  15. Re: Does xSTO handles storing in Port 2 properly ?

    On Nov 8, 11:45 am, "manjo" wrote:
    <...>

    > Actualy:
    > the best would be if a new prologue was introduced for variables
    > based or containing ARM code.
    > These objects would *always* be kept on 32-bit aligned address thus capable
    > of running instantly.
    > (no need to relocate anything anywhere -capable of immediate execution)


    It's called ARMCODE object, and it already exists. It can be EVAL'ed
    just like a regular CODE object, it is stored with FIXSTO when you
    store it in flash, and flash bank repacking keeps ARMCODE objects
    properly aligned automatically.
    But it's still behind closed doors...

    Claudio


  16. Re: Does xSTO handles storing in Port 2 properly ?

    Hello Claudio

    > If STO did all that automatically, then why would I bother writing

    the
    > Flashtools? :-)
    > The idea is that when your flash is full of objects, you can

    manually
    > "optimize" which lib goes where, so that you can get the best out

    of
    > it.

    Yup, that makes sense as well. That´s why I say that port 2 is still
    under construction because that is the job xSTO *should* do.

    Thanks for your information how storing in port 2 is working at the
    moment.

    > That's what STO/RCL is meant for. A single access method.

    If it would working, you wouldn´t write a replacement for it, would
    you ;-)

    As a conclusion we can agree on the fact that xSTO is only working
    partially for port 2 and that there will be no fix for a real working
    version by HP soon.
    And that the memory availabe there can not be used to it´s full/normal
    characteristic.

    > That's what STO/RCL is meant for. A single access method.

    *Meant* is the right word in this case and far away from a single
    access method, leaving behind confused user who do not understand why
    the can´t store their stuff in port 2 even if they have enough ram and
    port 2 reports enough free memory. I would´nt even call that a beta-
    release...

    > OK, so you *were* using an ARM model, and there's no need for me to
    > try and find a bug, right?

    Yes, flashbank E and F is only shown in the top row of the screen but
    the cursor refuses to go there (as intended by you I guess).

    Sorry for confusing you. Yes, I only have an ARM-Model available
    anymore as my 49G stopped working a year or two ago and only
    continuously beeps and shows the TTRM screen flashing together with
    the beep. I even left the batteries out for a couple of month but it
    does not come back alive. It probably needs surgery for reanimation...

    Greetings
    Andreas


  17. How STO selects & repacks flash banks

    On Thu, 08 Nov 2007 13:45:56 -0600, Claudio Lapilli wrote:

    > On Nov 7, 5:19 pm, Andreas Möller
    > wrote:
    >> Hello Claudio,
    >>
    >> that makes sense ;-)
    >>
    >> An empty 49G reports 1021 kB in the filer, divided by 128 this is
    >> almost 8 which would be the FlashBanks 8-F.
    >>
    >> An empty 49G+/50G reports 768 kb in the filer, divided by 128 this is
    >> almost 6 which would be the FlashBanks 8-D. IIRC the 2 Banks are
    >> needed for the saturn emulation.
    >>
    >> Now talking about storing a large item, a lib with around 120 kB:
    >>
    >> Say, for example, if in all Flashbanks something is stored so that the
    >> 120 kB is not available but the objects in all Flashbanks are small
    >> enough so that they could be moved to another bank to free a 120 kB in
    >> a single Flashbank. Does xSTO (given enough RAM of course) handle this
    >> and moves the objects into annother flashbank trying to free up memory
    >> like I can manually do with [CUT] and [PASTE] and [PACK] in Fman.bin ?

    >
    > If STO did all that automatically, then why would I bother writing the
    > Flashtools? :-)
    > The idea is that when your flash is full of objects, you can manually
    > "optimize" which lib goes where, so that you can get the best out of
    > it.
    >
    >>
    >> I did not find any information about how storing in Port 2 works
    >> *exactly* and the reported number by xPVARS or the Filer is
    >> misleading. It happens quite often to me that I try to store a large
    >> object and it seems that there is enough memory but actually there is
    >> not.

    >
    > The information is not readily available, but basically STO works as
    > follows:
    >
    > 1) Find the bank with smallest free space that can contain the lib. If
    > any bank can contain it, then store it.
    > 2) If no bank can contain the object, then find the bank that has most
    > wasted space and PACK it. Then retry storing.
    >
    > Banks are 100% independent, no objects are ever 'moved' from one bank
    > to another (and that's why you need Flashtools).
    >
    >
    >>
    >> Memory management of Port 2 is not very transparent and far away from
    >> an optimized way ...
    >> Trying to hide the limitations of the system to the user leads to
    >> quite some surprising and incomprehensible results and even more
    >> confusion instead of easing the use.

    >
    > But then you would have yet another thing to learn on an already steep
    > learning curve.
    >
    >> At least a single access method for system RPL is desirable instead of
    >> needing to dive into ML for storing into Port 2. That´s what operating
    >> systems are there for ...

    >
    > That's what STO/RCL is meant for. A single access method.
    >
    >>
    >> > There's no bank E and F in the newer ARM models, and it seems FMAN

    >> is
    >> > detecting that your machine is an ARM model.

    >>
    >> E and F is only shown in the top row of the screen. But in contrast to
    >> pfree.bin the cursors does not move to this banks, same with ERAM 2
    >> which is used by the ARM models as well.

    >
    > Because the old pfree was written long before the ARM models were
    > created. It simply shows garbage (and it may crash depending on that
    > garbage).
    >
    >
    >> So it works quite well on a 49G+ but I got confused by the content of
    >> bank E and F as pfree.bin (as the ancestor of Fman.bin) behaves
    >> different this way

    >
    > OK, so you *were* using an ARM model, and there's no need for me to
    > try and find a bug, right?
    >
    > Claudio
    >
    >



  18. Re: How STO selects & repacks flash banks

    Oops... that was supposed to have been a "Forward," not a "Reply" -- Ignore!

  19. Re: Does xSTO handles storing in Port 2 properly ?

    On Thu, 08 Nov 2007 13:45:56 -0600, Claudio Lapilli wrote:

    > Find the bank with smallest free space that can contain the lib.


    Is "free" space calculated in terms of:

    o Total space not occupied by non-deleted objects?

    o Remaining space between "current end of data" and "end of bank"?

    Consider a bank almost filled with deleted objects, for example;
    the first measure of "free" space in that bank would be high,
    while the second measure would be low.

    Thanks.

  20. Re: Does xSTO handles storing in Port 2 properly ?

    If one did not have Flashtools, but did have an empty SD card,
    perhaps one could move all Port 2 objects to the SD card,
    then erase the Port 2 "user" banks (oops, need a special function),
    then sort the SD objects in Filer, smallest first,
    select them all in that order, and copy them back to Port 2?

    I haven't yet looked to see whether Flashtools makes use
    of an SD card, or otherwise can re-arrange all banks by itself;
    if it doesn't, perhaps another program could automate the entire thing?

    In my emulator (of a 49G), PFREE shows me the following:

    Bank 8 - lots of non-deleted objects
    Banks 9, A, B - absolutely empty
    Banks C thru F - objects (some are deleted)

    Following Claudio's explanation of STO logic,
    I don't quite see how the "middle" banks remain unused,
    while only the "end banks" contain objects?

    Well, maybe I do see -- Bank 8 came with Equation Libs
    pre-installed, so it was used until full,
    then subsequent searches for a bank
    start looking in highest banks first?
    (or perhaps, when "eligible" banks are equal,
    the last "equal" bank is the one selected?)

    Does Port 1 have the same restriction, that objects
    must be less than 128K, and can not "straddle" the two banks?

    -[ ]-

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast