I don't think that rule is needed at all since the entries will be compiled by the judges to ensure legitimacy, the executable alone can't be acceptable as an entry anyway.

Also, as far as using other people's code, I think a good rule of thumb is this:  If you can tell that entries look too similar to existing public projects without even looking at the source it will probably affect your originality score.  But, if you use someone else's code, even if you use a lot of it, but use it in a unique and creative way, then there is no problem with that.

The cool thing about subroutines is that you don't need to understand the code.  Once you know what the subroutine does, you just put it everywhere you need it and never think twice about it.

Try this.  You can flash the red pixels on and off for the flame.

That's becasue the symbol table also holds a copy of the size and the OS uses that when calculating how much ram you have.  I'm almost certain that there is no one location that holds the current ram amount.  Instead, I think the bcall calculates the ram available by reading through the entire symbol table each time.

By the way, I think this has kind of gone off topic since this thread is mainly for sharing projects.

Yeah, it should be able to read archived source files now.  But it definitely shouldn't crash the calc.  I don't know why it would do that... but again, this is a temporary feature.

What is that last number?  You shouldn't have "L" in your code anymore since you're using X and Y instead.  Also, I can't really help without seeing the code you're using.

EDIT: nevermind, saw your edit, will look at code.

EDIT2:

:{*120+(D/2)}→C

should be

:{*120+(D/2)+Q}→C

Alright, I made a big modification.  Its now only 7 bytes larger than the original routine now, still doesn't need to be initialized, and is significantly faster and better looking, but still just slow enough to work on any LCD without having to run fixer programs.

The only downside is that I use a shadow register.  That means this command should NEVER be used in an interrupt routine.  That's alright though becasue you should never have LCD commands inside of an interrupt anyway.  Its much better to just have the interrupt control a counter and then your drawing routine updates the LCD depending on the counter.

Let me know if this can be optimized more and still run on the slower LCDs.

p_Disp4Lvl:
di
ld a,$80
out ($10),a
ld (OP1),sp
ld sp,appbackupscreen - plotSScreen
ld e,(plotSScreen-appbackupscreen+12)&$ff
ld c,-$0C
ex af,af'
ld a,%11011011
inc (iy+asm_flag2)
jr z,__Disp4Lvlskip
add a,a
ld hl,(flags+asm_flag2)
inc l
jr z,__Disp4Lvlskip
rlca
ld (iy+asm_flag2),-2
__Disp4Lvlskip:
ld l,plotSScreen&$ff-1
ex af,af'
__Disp4Lvlentry:
ld a,c
add a,$2C
ld h,plotSScreen>>8
inc l
ld b,64
out ($10),a
__Disp4Lvlloop:
ld a,(hl)
add hl,sp
xor (hl)
ex af,af'
cp e                              <-- Epic coincidence that e just happened to be between 182 and 219
rra
ld d,a
ex af,af'
and d
xor (hl)
out ($11),a
ld d,(plotSScreen-appbackupscreen+12)>>8
add hl,de
djnz __Disp4Lvlloop
inc c
jr nz,__Disp4Lvlentry
__Disp4LvlDone:
ld sp,(OP1)
ei
ret
__Disp4LvlEnd: