In ASM, bcalls starting with "Create" are used to create a variable. Where the variable data is, there are two bytes denoting size, followed by the rest of the variable data. The question is whether that data is zeroed out before the bcall returns.

When you create an application variable, assume random garbage is already there, it is not automatically set to 0.

Wait, so what is the error right now?  Is it the 65535 size error or is Mirage actually changing the high scores?

Hehe, I love this thread's new title...

i found a glitch.
the blocks have a possibility of overlapping with the path of your snake. when the end of the snake reaches and tries to delete the overlapped section, the end changes direction and grows until it hits a wall, when it then recedes until it gets back to the blocked section. and then it grows.. and recedes.. over and over. i had a whole screen filled up because the end wouldn't delete itself (:

I saw your update on ticalc, but what happened to your download count?? Either your former file dissapeared from ticalc or you created a duplicate author accounts. Otherwise, could it be because you uploaded the file in a different directory?

really? Because I saw it in ticalc.org archives for one week. It was even in the recent files list. It was uploaded around the same time I uploaded my old files on ticalc and the author name was yours. It was updated once during that time, too

The only difference is that the version uploaded at ticalc.org last week was under MirageOS rather than just ASM games