[no subject]

(I did write a level editor of my own, in order to let me override the 
protection and inspect the actual Lode Runner disk.  It is written in 
FPBASIC, uses Flex Type for graphics rendering and some MECC code for 
drive access, and can be found at 
http://xtra.usotsuki.info/lodehax.dsk.gz - it wants the disk in drive 2.)

> Depending on the kind of redundancy in the levels, it's possible that
> a simple run-length compression would do nicely, and both compressor
> and decompressor would be less than a page of code.

Prolly... and could replace the (DOS 3.3) RWTS code already present.

If through refactoring the game can be made to fit all its data and code 
below A000, that would allow even more room for levels.

I've been trying to disassemble it - but I don't really understand what I 
see.  (If anyone else wants a stab - the game's entry point is $6008.)  I 
have found the location of "start game", "editor command line interface", 
"level editor", and a couple other things.

(A memory dump, called postmortem.bin, is in the file 
http://xtra.usotsuki.info/lrrl.zip .  I can probably upload the current 
result of my work with IDA, including some labels, but it's not done and 
would thus not be very useful.)

> On the other hand, it seems unlikely that the compressor would need to
> be resident, unless the levels are updated (that would mean disk writes
> in the original game).

Very true.

> Practically any decompression routine will take a pointer to the
> compressed data and a pointer to where the result goes, possibly
> plus a maximum length to prevent disasters.  Then a JSR gets the
> job done.

And to make it easier, I think the output block is always 0D00.0DFF.

-uso.