Seems fine to me too. I think the size increase will be worth it for games that are rather complex in terms of maths.

Good news!  I've found the source of that error where the high nibble sometimes gets changed to a 0.  My byte reading routine was supposed to preserve certain registers and I forgot that I changed that routine by adding another subroutine to it that shows the current progress percentage and that subroutine did not preserve those registers when it updated the percentage to the screen (which happens very rarely).

Good news!  I've found the source of that error where the high nibble sometimes gets changed to a 0.  My byte reading routine was supposed to preserve certain registers and I forgot that I changed that routine by adding another subroutine to it that shows the current progress percentage and that subroutine did not preserve those registers when it updated the percentage to the screen (which happens very rarely).

So this is the source of my hexadecimal parsing error? One thing I did notice is that the percentage counter updates while parsing hexadecimal data in 0.4.0 and above, and that's when the problem appeared. I was even thinking to myself, asking if that could be the cause of the problem, but I figured it probably wasn't and didn't think to mention it lol.

EDIT: Oh, and on the topic of the percent counter, there's another bug, although it has no adverse affects and will hardly ever show up: if the program you're compiling is absolutely massive (like both of the 2 ~48K uncompressed map data source files I have), the percent counter loops back around to 0 percent in the middle of compiling, I believe once ~32768 bytes have been processed.

Well these are pure hexadecimal source programs, so the size of the "executable" programs are less than half those of the source and fit individually RAM. Every two bytes of source hex become one byte of compiled hex, and the comments, line breaks, and brackets disappear, leaving only 20.5K each. What did you expect though, the entire overworld from Link's Awakening is pretty big. But I've managed to compress the two 20.5K uncompressed tilemap data programs into one 19K appvar thankfully.

Programs can be larger than 16kb since they can take up all available ram, they just can't be executed.  Runer is using those programs as read only memory so he doesn't have that problem.  But I didn't know myself that programs could be larger that the available RAM!  I guess they would have to be archive only, made on the computer, and then transferred.

THAT WOULD BE INSANE!

Programs can be larger than 16kb since they can take up all available ram, they just can't be executed.  Runer is using those programs as read only memory so he doesn't have that problem.  But I didn't know myself that programs could be larger that the available RAM!  I guess they would have to be archive only, made on the computer, and then transferred.

Mhmm I am a bit confused by what read-only means. Do you mean the archive memory? I am curious how he actually run them

I think it just means he is using it as Level data, and since its data it doesnt matter if its in archive, ram, or if its less than the 8800 bytes limit.

Incidentally, I could never understand why ASM programs must be 8 KB or less.  Can anyone explain?