How do you do it in pure BASIC?
Subroutines and archiving?

Depends, what kind of text are we talking? Dialogue? Data?

Dialogue and map data.
And some UI elements.

"Most efficient" really depends on
a) The content of the data
b) What you mean by efficient in terms of time/memory tradeoffs.

What kind of assembly/library do you plan on using? I could easily explain how to do this with Celtic2 (I'd have to set up a download for you to grab it from, since I don't think there's a release anywhere of the working version) though I think Celtic3 has the same libraries, just different ways to call the commands.

Anyways, you can store large blocks of dialogue into an appvar using a format similar to what is found in http://www.ticalc.org/archives/files/fileinfo/409/40966.html

Map data can just be stored to a single line per map and recalled with celtic. I could probably pull some sample code out of pokemon somewhere to show how C2 handles it.

Efficient memory-wise.
Content is text only.

And this is in pure BASIC.

You could use RLE compression to save some space, but I don't think it would be very helpful for dialogue. Without an assembly library, storing large amounts of text efficiently is going to be fairly difficult, since there are only 10 string variables. If you do end up using an assembly library like Celtic, you could create appvars that hold text and archive and unarchive them when you need to.

You could go the list route for it. Where you use every element of a list, with each digit of accuracy to store data. ie, you could have a list that was: {0805121215}, which would stand for the world "HELLO" ('H' being 08, 'E' 05, 'L' 12, etc), and then just decompress that list when you need to. The benefits are: you can have an arbitrary name for the data and you can archive the data. The downsides are: you have to have all the data in RAM and it is difficult to edit/find specific letters in (ie, character 212 to 218).

That doesn't answer the question. Being able to compress something efficiently depends on data to have some structure or patternedness that can be exploited to shrink the amount of memory required for storage without losing data.

Text generated by a random number generator probably won't be very amenable to compression (unless you know the algorithm + seed, and have a lot of spare CPU cycles). 1MB of the letter A has insane redundancy and perfect order. Human language, or ascii art, or pretty much anything meaningful, will probably fall somewhere between those two.

Context is dialogue and map data plus some UI elements.

I just noticed that Raylin writes ridiculously short posts that are not full sentences, with one thought per line. RLE does not succeed well at compressing text. Something like LZO would be much better at text, but implementing an LZO algorithm is nontrivial if you've never done it before (I have but not in BASIC or ASM; it was C). Breaking it up into the map in appvars, the dialog in related appvars, and the UI in its own appvar would probably be good. It might also be a smart idea to combine related map and dialog areas together in appvars.

Hush yo face.



But then, the program ends up being hybrid BASIC.
Then, I cry because hybrid BASIC can't compete with Axe.

And then we cry because we don't care if it competes with Axe or not, as long as your output program is cool and fun.

This is for the contest.
I will lose if I enter Hybrid BASIC with a program intended for pure BASIC.
That's the opposite of winning.