[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)
Weird. Wat about clearing your RAM and look again?
>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
>> >
>> >
>> >
>>
>>
>>
>> >>
>>
>>
>>
>>
>
>
>