Hmm... failed to initialize the LCD row value?

I just typed your code into my calculator and I didn't get any lines at the bottom of the screen. Only thing I did differently was leave off the ending parenthesis but I don't think that'd change anything.

Sounds like there might not be enough delay.  That surprises me since it works on mine and I have the slow LCD driver.  What model calculator are you using and what letter on the back?

Quote from: meishe91 on June 17, 2010, 03:18:18 am

I just typed your code into my calculator and I didn't get any lines at the bottom of the screen. Only thing I did differently was leave off the ending parenthesis but I don't think that'd change anything.

Are you using Axe 0.3.0?
And if so, what exactly did you leave away?

Ya, I'm using 0.3.0. I actually tried both and got the same results. The only things I left off though was the ending bracket ("]") and the ending parenthesis to the second and fourth Pt-On( command.

This was done on a TI-84+ running OS 2.43. Which letter on the back is it that you look for again? I can't remember.

Is it possible you were just running a different program previously that might have changed the LCD settings?  See if ALCDFIX makes it work again.

^ yes it does.. for quick example, look at new rpg demo

That's because both the arguments to Fill( are 16-bit numbers, and such numbers can be construed as pointers.
What Fill(200,L1 does is fill L1 bytes starting after the 200th byte, which is something very undesirable.
Basically, there is no way to detect it, because the arguments are indistinguishable.

I'll try again
A 16-bit number (two bytes) is the type of number generally used in Axe (one byte numbers are used, though with slightly less frequency)
Fill( takes two arguments. The first one is the address from which the fill starts. The second one is how many bytes to fill.
Both of these arguments are 16-bit numbers. The first one is a pointer, the second one just a number. However, despite their very different roles, they look exactly the same to the compiler. So a check is impossible. Also, the overhead necessary to check if you're doing something silly like trying to write to flash (anywhere from the first 16384 to 32768 bytes are flash) is too large and unwieldy.
Note that ASM, or Axe in this case, gives up safety checks for speed.