Thx for feedback Dapiano.
Much appreciated =]

Well good luck, then.
I was concerned because the huge size of those files makes them unarchivable, and thus uneditable, unless you edit the flash directly, which is dangerous and hard as F***.
Really, you can handle sector boundaries, but not signatures?
I understand lol

Well that'll cause some wear on the archive, but since EVERYBODY focuses on writing to flash as little as possible, even after years of use with this program, it may not ever be a noticed effect. Nobody has ever worn their chip to the bone.
You do realize that will require AT LEAST 1 page of free user archive space, no matter what?

Quote from: Dapianokid on April 20, 2013, 10:01:28 am

the_mad_joob as far as I know, you can't. I've tried it with many programs and utilities, the maximum, even if sending directly to archive, is however much USER RAM you have left.

Since i wasn't sure, i decided to give it a try.
The good news is that it works =]
I mean, the OS can totally handle very large variables properly, as soon as they don't cross a sector boundary.
For what i've tested, the ultimate size (actual data) of an archived appvar|group|program is exactly 65522 (name length = 1 in that case).
Of course, such variables cannot be unarchived.
I used wabbitemu for now so i'm not sure yet if ti connect lets you send such files.

Anyway, i prefer to use appvars more than apps, mainly to avoid space loss (and dealing with app signature stuff i must confess =P).

Don't quote me on it, but I'm pretty sure that files can be larger than that. I seem to remember DJ Omnimaga saying he's sent apps (songs made with realsound) that took up most of the archive to his calc before. I just takes a very long time, and the calculator did fail sometimes with larger files. You might do good to set a limit regardless, as things will get slow sending larger apps(from what I've heard). Also, I know all Ti-84s have at least 64k of extra RAM, but what about the 83+? If it is less, will it be a issue?

Don't quote me on it, but I'm pretty sure that files can be larger than that. I seem to remember DJ Omnimaga saying he's sent apps (songs made with realsound) that took up most of the archive to his calc before. I just takes a very long time, and the calculator did fail sometimes with larger files. You might do good to set a limit regardless, as things will get slow sending larger apps(from what I've heard). Also, I know all Ti-84s have at least 64k of extra RAM, but what about the 83+? If it is less, will it be a issue?

I've already decided not to use apps for file storage.
About the total ram, it can go from 48k to 128k, as far as i know.
It won't be an issue, since the usable amount will be auto-detected.
Of course, trying to edit, let's say, a 64k file, will only be possible on models having 128k of ram, tho it will be possible to view that file on other models.

****

A problem i'm currently facing :
When i want to manually add an appvar to the archive, it fails (doesn't appear in mem mgmt).
Here is what i currently do :
- write the appvar in archive
- write the corresponding entry in vat
- adjust (ptemp)
Something else must be done but i dunno what.
Probably another pointer to adjust...

****

EDIT :
Dumb me...
Also got to adjust (ops) & (opbase), maybe (freeram) too.

Okay EDITING can be done like this:
Just archive the file, and create a copy in archive/RAM to edit. No need for extra RAM.
Might be slow, though.
By the way, theoretical App size could be as big as 1.07 gigabytes (1 073 725 440) but the largest I"ve ever sent to my calc was 15XX kilobytes (maximum size)... Tilp crashes on that stuff lol

Archive works like this:
You can turn a bit OFF, but you cannot turn a bit ON unless you erase the whole 64KB sector. That is the challenge.

I would also like to point out that 1.07 gigabytes is about 1000 times as much archive space as any of these calculators have Also, I think you are assuming that it uses a two-byte page size when it actually uses 1 byte. Apps are stored in a completely different format than other variables

I was just pointing out that the_mad_joob has a fairly decent method that he is employing as it currently is Note that the flash chip is limited in how often it can be written to, so it would be best to do all of the editing in RAM and save to flash once everything is done.