Half byte smooth scrolling IS feasible with the intelligent use of subroutines.  Instead of reading the tiles using the simple single byte system {Y*width+X} you can read them with a subroutine that takes X and Y as input and then outputs the tile.  So it effectively becomes no more difficult than regular full byte smooth scrolling, you just have to add the additional subroutine.  You can even modify an existing smooth scrolling engine to become half byte compatible.  I wrote a subroutine you can use here.  The speed should not be very different than full byte when done correctly.  One speed optimization you can do is /2/2/2/2 instead of /16 if you do run into slowdowns.

There will eventually be some on-calculator help.  That's why the help button is there.  It will take a lot of time to write though, which is why I'm not going to add it until the end.

I don't know exactly what is the reason for it, but my program that started within a second with version 0.2.5, now takes 2 seconds to startup. is this perhaps because of the interrupts? of could it be so because of I start my program with a pretty complex for-loop? Has that become slower?

Are you unarchiving something at the start of the program?  Garbage collecting can make it go much faster if archiving/unarchiving begins to slow down over time.

You don't have to delete your post, there's nothing wrong with announcing it.  Its only if you feel that your project is at risk of being copied or having a story line that could be spoiled that I would recommended giving away less details.  Its nice to have at least a name or codename so at least people know what you're working on.  And by announcing your projects you can get other people's opinions and suggestions of what they like to improve your entry even more.

First thing I noticed is that you're scrolling by 2 bytes at a time when moving left and right since these are half bytes.  What I would to do make this less of a nightmare is to write a subroutine that returns the sprite number times 8 (the sprite index) at a given a coordinate position on the map.

:.Input
:.D=x-position
:.Ans=y-position
:
:Lbl XY
:{*120+(D/2)+data}→C
:If D^2
:C^16*8
:Return
:End
:C/16*8
:Return

Use different temporary variables if C or D are locked up.

This makes it much easier to draw maps and read tiles:
:For(A,0,11
:For(B,0,6
:A+X→D
:Pt-On(A*8,B*8,B+Ysub(XY)+Pic1)
:End
:End

Here I'm not using L, I'm using an X and a Y coordinate since its much easier to program and there is less math to do.  Only downside is that now you need 2 variables to keep track of position instead of 1.

X must be in the range 0-227 and Y must be in the range 0-133 otherwise you're drawing random garbage outside the appvar.

Yeah, I think it will be worth the size increase.  Its a 46 byte increase, but it has the added bonus that it doesn't need to be initialized with a separate command (after I modify this routine).  Also, I think there are a few places I can optimize to save on memory, but still not hinder the speed.

EDIT: Actually that code is pretty rock solid optimized, there were only a couple places I made improvements.

In the entry points, its better if the instructions are in this order:
ld a,c
cp $2c
jr z,__Disp4LvlDone
ld h,plotSScreen >> 8
inc l
ld b,64
inc c
out ($10),a
Because this way, it jumps out of the loop sooner when it gets to the end of the routine.  Not that big of a deal, but it saves several clock cycles each render.

Also, the jump table I changed to this:
inc (iy+asm_flag2)
jr z,__Disp4Lvlentry3
ld a,(flags+asm_flag2)
inc a
jr z,__Disp4Lvlentry2
ld (iy+asm_flag2),-2So that you don't need to initialize the byte that keeps track of gray layer since it falls through if the number was uninitialized.

Thanks again!  This does look a lot better  

Thanks!  Although that looks much larger than my current routine, I'll have to see if the improvement in speed/quality is significant enough to justify the size increase.  I'll do some more testing this week.

Quite simply, no.  Self modifying code is not possible without disassembly of the generated programs becasue you need to get the address of the instruction to modify.  This is a bad practice becasue future versions and new optimizations change the size and order of the code which means you lose compatibility with newer versions.  That doesn't even include the fact that every time you modify your code, you have to disassemble again to get the address since it changes with how many bytes come before the SMC.  And yet another thing, it doesn't actually save very much space nor speed especially for the effort you would have to go through to implement it.  This does require greater than average assembly knowledge to do.

EDIT: Oops! I misread your post.  If you just want a write back, you can do this with axe commands by copying the running program in ram (address _E9D93) into the program itself which you can get via the getcalc() command.  You can also get the size of the amount of data you need to copy with that command by reading the 2 byte number directly before the pointer.