I'm not sure if this has been asked, but what about a line( routine, will we have that soon?

woops, forgot about the first post being updated

Question:

How would somebody go about copying the entire content from an archived appvar/program into another, or parts of it? If for example, someone has a game with a lot of map data and it is spread between 3 appvars of about 7 KB each, currently, he has to use the Unarchive and Archive commands. However, in some cases, there would be a lot of archiving going on and loads of archiving means loads of defragmenting needed, wearing out both the player's set of batteries very fast and their Flash ROM as well (which happened to people, before, such as our last year TI-BASIC contest winner, Drummist).

If it is impossible, I wonder if it would be possible to implement a command that allows you to read bytes from an appvar stored in archive, or at least, something that can copy an entire program from archive into RAM?

For the later, you could ask Iambian if you could use XCOPY source for it if you need someone's routine. It may be useful in the future for people who wants to make slightly larger games (in terms of data, not executable code), but don't want to hinder the user with endless amounts of GarbageCollect messages (and risks of causing the game to crash/exit in improper ways due to him accidentally choosing No). Some of my old BASIC games got some bad reviews because of those.

[...] Also, since the BASIC game engine is too big to fit in ram, this means that there is quite a lot of archiving going on as you play... so be prepared for garbage collects every six minutes or so.

[...]

Overall: 12/40.
Perhaps on a Silver calculator, this game would be playable, but on an original edition it's just too frustrating to complete, unless you're the kind of person who enjoys spending money on batteries to see them drained by endless garbage collects. If it wasn't for this one point, this game would probably rate “Reign of Legends: at least a 30/40.

There is an ASM RPG called Final Fantasy v1.198 that won't fit in RAM and is split in multiple archived files. It copies the needed data in temporary RAM rather than unarchiving it. I think Desolate requires the data to be in RAM all the time, though.

Reading from archive isn't really that tricky, but it would certainly make the code a lot bigger and require new commands.  You can't just use a pointer; you have to switch pages, store data from that page to a register (temporary variable), switch pages back to the normal RAM, and then save the register into the RAM page at the desired location.  You have to do this for EACH byte or two byte combination you read which means its a lot slower than reading directly from ram.

I think it would really complicate things a lot and it would be about the same speed to unarchive it anyway as it would be to read all of the bytes from archive, although it would definitely be faster for individual bytes.  Putting the calculator in 15MHz mode during archive/unarchives is generally fast enough.  Reading a 6000 byte map by unarchiving would take less than a second to unarchive and especially for RPGs, a little loading bar once in a while isn't that big of a deal since it would never be in the middle of game play.  Just keep the data in ram until its no longer needed.

By the way, another trick I don't think many are aware of is that you can make the program archive ITSELF while its running so you effectively can use the entire free RAM if you need more.  Then unarchive it before you quit.

I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.

I don't think there's such a thing as garbage collecting messages in asm.  I could be wrong, but I've never seen it or heard about it before.  Its possible it might ask when the program quits and hands control back to the OS though.

I think you can trigger them in a call to _Arc_unarc, but I'm not sure. Anyway, I don't think the OS does 'sneaky' GC without warnings.

mhmm, I'm a bit confused I am not sure if I understand the concept well. What would be the benefit of libraries only including the sub routines you use in your compiled code when compiling a program normally alerady do this?

For example, if I have prgmA and it only contains .B in the code, the compiled version will be 13 bytes large (no-stub). In other words, stuff that is not used is not included, right?

I'm not sure if I get the concept

mhmm. Yeah I think I get it about the libraries. I guess they're like subroutines, but external?

I got stuck on the part saying this, though:

The nice thing about the libraries is that only subroutines you actually USE will get compiled into the code.

Since in the case of internal sub-routines, if there's a routine I don't need I just have to delete it altogether (and back it up elsewhere for later use), so there wouldn't be any advantage between using external and internal ones.

If it is unclear, I will probably move on for now, though, because it looks like there's something there that is way beyond my capacities of learning (of the moment) that I may be best waiting later to try to understand (at this point it will most likely be lost among 3 or 4 new pages of posts )