The current Axe Parser package includes a copy of RabbitSign, but it does not include the license, copyright statements, corresponding source code, or in fact, any acknowledgement of the program's origin.  Instead, it contains what is apparently a README file for Wabbitsign (which is an unrelated program with a similar name and function.)

RabbitSign is free software, licensed under the GNU General Public License.  That means that anyone is allowed to use, copy, or modify it however they like.  It also means that if you distribute it, you have a responsibility to inform users about their rights (including telling them where they can get the source code.)  It's up to you how you do so, provided you comply with sections 4-6 of the GPL.  What I would suggest, however, is that you simply include the COPYING and README files from the RabbitSign binary package (note that the README file includes a URL where the source code can be found.)

Please fix this as soon as possible.  Users have a right to know where the software they're using came from, and what they are allowed to do with it.

I believe it's actually encrypted using Wolbhsif

That's sort of what I was asking before, about whether you'd want to have the mask as part of the sprite or as something separate.

I was assuming you'd want to draw everything (mask and both image planes) in one pass, but using multiple passes is also an interesting idea; it would make the code much simpler (hence smaller), as well as more flexible, but also somewhat slower.

Oh, OK.  So you'd be looking at 18 bytes of wasted space per sprite, not 6.  Would you give every sprite its own mask, or share a mask between multiple sprites?

Also, I don't really know how grayscale works in Axe.  Which buffers do you use?

Pucrunch is designed to be asymmetrical - the PC does the considerably-harder work of compressing the data so that the decompressor can be fairly simple.  If you want to both compress and decompress on the calculator, you should probably think about using a simpler and more symmetrical algorithm.

Points to keep in mind:
- If you alter the mapping in the 8000-BFFF or C000-FFFF blocks, system routines - including the system interrupt service routine - will not work.  Most other stuff - e.g., shell library routines, many Axe builtin commands - won't work either.
- If you alter the mapping in the 4000-7FFF block, you must restore the original mapping before exiting your program.

Resizing one 8x8 sprite takes 0.1 seconds, meaning resizing 10 8x8 sprites would reduce your frame rate to 1 frame per second.

I'm not sure what exactly you mean - the time taken depends greatly on the size of the output, and less on the size of the input - but I don't think it's anywhere near as bad as you're suggesting.  I wrote a scaled sprite routine a while ago, which takes about that long to draw a sprite at 64x64 (masked, with both X and Y clipping.)  This, of course, is an extreme case.

Well, at first I thought the challenge was to store the sprite in a string in Ans (so you can recall it into an Axe program.)  Then I looked at SirCmpwn's version and realized the challenge was just to display the string on screen.

My first version (store the string in Ans) is 39 bytes of code:
        ld hl,16
B_CALL CreateTStrng
inc de
ld hl,plotSScreen
loop1: ld b,2
loop: xor a
rld
daa
add a,-16
adc a,40h
inc de
ld (de),a
djnz loop
ld a,l
add a,12
ld l,a
cp 95h
jr c,loop1
B_CALL OP4ToOP1
B_CALL StoAns
ret
(I feel like this could be optimized a little more.)

My second version (display the string on screen) is 26 bytes of code:
ld hl,plotSScreen
loop1: ld b,2
loop: xor a
rld
daa
add a,-16
adc a,40h
B_CALL PutC
djnz loop
ld a,l
cp h
ret nc
add a,12
ld l,a
jr loop1