SCREEN COMPRESSOR

by Guy Palmer



[The POKE 32921 mentioned in the instructions is the value of the]

[marker byte, which must not exist in the area to be compressed. ]

[The published version of the program expects you to guess a     ]

[suitable value - which makes it not a lot of use.  I've added a ]

[modified version which first checks for an unused value and uses]

[that. NOTE that a value of 1 cannot be used for the marker byte,]

[as it conflicts with the value used to initialise the workspace.]

[                                                           JimG ]



Good old Guy - he sends me loads of stuff, even though most of it

narrowly misses the printed page. His loyalty has paid off this month

though, he says in his letter: "If you like it, print it, and give me

the dosh. If you don't like it, then may your aubergines be denser

than a lobotomised chicken's mental capacity for cornflakes.". Yes,

Guy, I expect so. Sometimes I worry, I really do. Back to the business

then - save the BASIC using SAVE "name" LINE 9998, then use the

universally acclaimed Hex Loader to enter that bit of hex over there,

okay?

  The program then does the rest pretty much by itself, but it does

tell you the bits you have to do yourself as it runs. If you're

interested in the tech, here goes - it works by finding clumps of

similar bytes, and storing them as just three bytes. For example, if

the first ten bytes of a screen were all A7, then the program saves it

as 26 A7 10 [Wrong!! It would be 26 0A A7 - count then value. JimG],

instead of A7 A7 A7 A7 ... etc. The 26 tells the computer to put 10

A7s at a certain address. That's all there is to it, really.

Apparently, each screen is saved with a copy of the decompressing

routine, so you don't need to load it in first or anything. If the end

result of your compressed save is just garbage, Guy recommends a swift

poke - POKE 32921 with a number between 0 and 255, then try the whole

thing again.