[A83] Re: What is the problem with flash writes (in general)
[Prev][Next][Index][Thread]
[A83] Re: What is the problem with flash writes (in general)
Yes, potentially it could, unless TI has something planned for the 96K and
want to use all of it. (And TI *did* say they were planning to use the RAM
in a future OS version).
An interesting thing to note, I just looked at my SE's extra RAM and it has
seemingly random data in it. It's definitely not code, and it doesn't seem
to have any pattern as data either. Probably it really is random data
caused from a power loss or something. It was just odd as I expected it to
be all zero's like last time I looked.
-Dan Englender
----- Original Message -----
From: <ComAsYuAre@aol.com>
To: <assembly-83@lists.ticalc.org>
Sent: Monday, July 09, 2001 1:22 PM
Subject: [A83] Re: What is the problem with flash writes (in general)
>
> Couldn't the TI-83+ SE use 64k of the extra 96k of RAM as swap space
instead of an area in flash?
>
>
> In a message dated Mon, 9 Jul 2001 1:16:59 PM Eastern Daylight Time, "Dan
Englender" <dan@calc.org> writes:
>
> <<
> To my knowledge, yes, to garbage collect the OS must erase a 64K chunk.
> This is what I've gathered from my reading of AMDs docs, disassembled
source
> code, and my own testing anyhow. Also, I believe TI may have changed some
> of their archiving procedures between 1.12 and 1.13. I have a feeling
that
> on 1.13 the sector that comprises pages 08-0B is always used for swap.
This
> was not always the case on 1.12. This may have been due to some odd
issues
> when attempting to load apps with low free archive.
>
> And yes, it's always garbage collecting when it says so. To overwrite an
> app that already exists it must erase the sector that the app was in so it
> can write the new data. That require the other apps on that sector to be
> moved around. Even so, 1,000,000 is a lot of erases, I don't think we
have
> too much to worry about there.
>
> -Dan Englender
>
>
> ----- Original Message -----
> From: "Kirk Meyer" <kirk.meyer@colorado.edu>
> To: <assembly-83@lists.ticalc.org>
> Sent: Monday, July 09, 2001 1:01 PM
> Subject: [A83] Re: What is the problem with flash writes (in general)
>
>
> >
> > Interesting -- is this right: to garbage collect, the OS must usually
> erase
> > a ~64K chunk. This would mean this chunk has to be backed up to
somewhere
> > else in FLASH. After it has been erased, it would be copied back. It
would
> > seem like the swap area where things are swapped to (unless it is not
> > constant) would set the minimum FLASH life -- since it would be getting
> > written to by far the most. I assume that this is the meaning of the
> > sections of FLASH designated "SWAP/USER" in the SDK guide.
> >
> > I hope the calc isn't always actually garbage collecting when it says
> so --
> > for example, when overwriting an APP that exists, it garbage collects?
> Seems
> > wasteful. But if the life is really 1,000,000 cycles, that's probably
> longer
> > than the other equipment will last.
> >
> > -----Original Message-----
> > From: assembly-83-bounce@lists.ticalc.org
> > [mailto:assembly-83-bounce@lists.ticalc.org]On Behalf Of Dan Englender
> > Sent: Monday, July 09, 2001 10:46 AM
> > To: assembly-83@lists.ticalc.org
> > Subject: [A83] Re: What is the problem with flash writes (in general)
> >
> >
> >
> > The way the Flash chip works, you have to erase either the whole chip,
or
> > whole sectors (sectors vary in size between 8K (only two of these) and
64K
> > (most are this size)). This is what wears the flash (and what causes
your
> > screen to dim...noticeable especially on HW1 TI-92's and TI-89's ... but
> > also on the 83P when you're loading a new OS) and there's not much way
to
> > get around it. So, if you need to *set* any bits on the sector, you're
> > going to have to erase it. If you wanted to set some bytes to zero, you
> > wouldn't have to erase first. You can reset bits whenever you like, but
a
> > set requires an erase.
> >
> > Hope that's clearer (erase loading 0FFh causes some mix-ups in
> terminology),
> >
> > -Dan Englender
> >
> >
> >
>
>
>
> >>
>
>
>
>
References: