this is brilliant!
i can't wait to test it out against you folks

i converted the intro sequence to 4 level grey, just for fun (it would have to be compressed rather well to actually use it in a game, however).
oh, and since i recently set up that SDK jonimus is hosting for my PRIZM...

i'm not sure why this thread is suddenly up again, but i decided to make one to add to the collection

i don't think so.
from what i've gathered, reading what thepenguin and wikipedia had to say, if string 1 is the uncompressed data and string 2 is the compressed data.

1. have a pointer set to the beginning of string 1 and look back through previous parts of string 1 to find sections that match the current position.

2. if there isn't any match (as will be the case when you start, because there isn't any previous data to look back at) write the byte directly to string 2 and move the pointer in string 1 forward one byte; if there is a match, write the pointer value and size of the section matched in string 1 to string 2, and move the pointer in string 1 forward to the end of the section that was matched.

and then, when decompressing

1. check if the current section in string two is indicated as compressed or uncompressed
2. if it's uncompressed, write directly to string 1 and move the pointer in string 2 forward to the next section; if it's compressed, copy the data indicated in string 1 (which you have already uncompressed and written, because the decompression is linear) to the end of string 1, and move the pointer in string 2 to the next section.

i was wrong before when i said the pointer is to a section in the compressed data. it really points to a section in the UNcompressed data, which makes a lot more sense because there's more data available in which to find matches.

here is it: link

it's a bit confusing to use, but a lot simpler than writing your own routines =)

alright, well that's a start  
what his compressor does is check for the same string of data occuring twice. the compressor looks at the compressed data it has already written and searches for a byte that equals the byte it's currently at in the uncompressed data. if it finds that byte, it then looks at the next byte in the uncompressed data and checks if that one matches up with the byte after the one it found in the compressed data as well. it keeps doing this until two of the bytes don't match. if the compressor wants to be absolutely certain that it has found the best possible match for the current point in the uncompressed data, it can store the position and size of the data that matched there and continue searching through the rest of the compressed data up to its current position in the same way, storing the new position and size if it finds a better match(one that is longer). it then writes the position and size of the best match in the compressed data and moves to the point in the uncompressed data that follows the section just matched. conversely, if it never found a match, it writes a 0, stores a 1 into the next 7 bits, and then adds the byte to the compressed data. it then moves to the next byte in the uncompressed data, and, if it can't find a match for that one either, adds it to the compressed data and updates the 7 bit number to hold a 2 instead.

since this compression method depends on matches in previous sections of the compressed data itself, when you first start compressing, everything will initially be stored as uncompressed data, as there is nothing  to search through to find matches yet. also, you can change the number of bytes in a row that must match for the match to be considered "good enough" to be added as compressed data. depending on the file, this could either increase or decrease the resulting size, so it's a good idea to include an option to define this size yourself prior to compression and then test different sizes to see which comes out best.

in review, the compressing program looks through the data that has already been compressed and tries to find a string of bytes that matches the one it's currently looking at in the data. in the example, once the compressing program reaches this point in the data:

00 01 02 03 04 05 06 07 08 09 00 00 | 06 07 08 09 00 00 06 02 03 04 05 06 08 09 04 03 06 06 06 06 06 06 06 06 06 06 04 04 05 08 09 09 01 01 01 02 03 04 05

Key:
(1 bit)
8 bits
[11 bits]
{7 bits}

and if it has a minimum match length of 3 bytes, it will currently have this much compressed code written:

(0) {12} 00 01 02 03 04 05 06 07 08 09 00 00

and the next section written in the compressed data will be this:

(1) [7] {6}

where the (1) indicates that the next section is compressed,

[7] indicates that the data to be compressed begins 7 bytes from the beginning of the compressed data, and

{6} indicates that 6 bytes are to be referenced from that point, those 6 bytes being 06 07 08 09 00 00

the compressor will then have this much written to the compressed program:

(0) {12} 00 01 02 03 04 05 06 07 08 09 00 00 (1) [7] {6}

and will be at this point in the data:

00 01 02 03 04 05 06 07 08 09 00 00 06 07 08 09 00 00 | 06 02 03 04 05 06 08 09 04 03 06 06 06 06 06 06 06 06 06 06 04 04 05 08 09 09 01 01 01 02 03 04 05

EDIT: i wrote this without having ever used this compression method myself, and just noticed that LZ77 looks through the UNcompressed data when searching for matches rather than the compressed (which makes a whole lot more sense, now that i think about lt ) otherwise, though, this should still hold true.

Would you perhaps be so kind as to write me a routine that compresses and decompresses a file? Or perhaps psuedocode it.

isn't that just asking for him to write the entire thing for you?
also, i was under the impression that more complex compression formats like this were compressed off-calc because the calculators have too little RAM to handle it. (see Iambian's pucrunch programs).