Re: A89: the VAT
[Prev][Next][Index][Thread]
Re: A89: the VAT
That is the way I understand it also. Your description shows that
everytime you archive something, it is written to Flash. And NOT just
when garbage collection takes place.
On Mon, 18 Jan 1999, Miles Raymond wrote:
>
> Let me explain it the way I understand it.
>
> Here's a map of a section of your RAM and a section of your FlashRAM (archive) and the variable x is
> in RAM:
>
> variable x
> /------------|------------\
> 001010101010101010101010101000000000000000000000000000 (RAM)
> 000000000000000000000000000000000000000000000000000000 (FlashRAM)
>
> here's how it looks when you archive it:
>
> 001010101010101010101010101000000000000000000000000000 (RAM)
> 001010101010101010101010101000000000000000000000000000 (FlashRAM)
> \------------|------------/
> variable x
>
> it is not deleted in the RAM, but it is copied to the FlashRAM and then changed in the VAT. This is
> what it would look like if you then Unarchived it:
>
> variable x
> /------------|------------\
> 001010101010101010101010101000000000000000000000000000 (RAM)
> 001010101010101010101010101000000000000000000000000000 (FlashRAM)
>
> it would be copied from the FlashRAM to RAM and then the VAT would change to point to the RAM
> address instead of the FlashRAM address. Then if x is changed to 001011111000111011100000001, the
> map would look like this:
>
> variable x
> /------------|------------\
> 001011111000111011100000001000000000000000000000000000 (RAM)
> 001010101010101010101010101000000000000000000000000000 (FlashRAM)
>
> the FlashRAM would remain the same and the variable x would be updated. The VAT would remain the
> same. Then we Archive x and the map now looks like:
>
> 001011111000111011100000001000000000000000000000000000 (RAM)
> 001011111000111011100000001000000000000000000000000000 (FlashRAM)
> \------------|------------/
> variable x
>
> where the variable is copied into FlashRAM and the VAT is updated. This is how I understand it to
> work. The garbage collection comes in when there is not enough consecutive space in the FlashRAM to
> stor something, and then all of the empty space is condensed, much like defragging a hard drive.
>
> -Miles Raymond EML: m_rayman@bigfoot.com
> ICQ: 13217756 IRC: Killer2 AIM: MRayMan
> http://www.bigfoot.com/~m_rayman/
>
> -----Original Message-----
> From: Michael S. Davis <ipscone@halcyon.com>
> To: assembly-89@lists.ticalc.org <assembly-89@lists.ticalc.org>
> Date: Monday, January 18, 1999 11:29 AM
> Subject: Re: A89: the VAT
>
>
> >On Sun, 17 Jan 1999 TGaArdvark@aol.com wrote:
> >
> >> > I did not post this program, but its idea originally came from me. Its
> >> > purpose is to degrade your flash-rom to the point of replacability near the
> >> > end of your warranty, thereby getting you a brand new flash-rom chip and 6
> >> > months of extra warranty. repeat ever 5 months...
> >>
> >> It doesn't work though because the calculator doesn't erase unarchived
> >> variables and the calculator does not write a variable to the archive
> >> more than once per garbage collection, no matter how many times
> >> you archive or unarchive it.
> >
> >I guess I'm confused. I have also read about this 'garbage collection'
> >but...
> >
> >1) Create a variable (located in RAM, right)
> >2) Archive this variable (located in Flash, right)
> >3) Unarchive a variable (moved to RAM, right)
> >4) Change the variable (still in RAM, right)
> >5) Archive that variable (isn't this moved to Flash, if it is it must
> >be rewritten, since it was changed). Or is it still in RAM? If so then
> >archiving does not archive. How does one to know if something is in RAM
> >or Flash, if it not putinto Flash when one archives?
> >
> >----------------------------------------------------
> >Shoot-to-Win
> >
> >Protect the 2nd Amendment
> >----------------------------------------------------
>
>
>
----------------------------------------------------
Shoot-to-Win
Protect the 2nd Amendment
----------------------------------------------------
References: