Quote from: Builderboy on August 03, 2010, 04:28:57 am

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?

It is because the RAM located at addresses $C000 to $FFFF cannot be executed, only read/written. So the limit on amount of executable code is $C000 minus $9d95.

That's not supposed to happen at all! o.o

What do you have archived?

That was the problem I had with 0.4.0 and was fixed in 0.4.1.  There is a bug in the TI-OS that thinks that pages starting with $FF are set for deletion and so it deletes the second page of the Axe app during defragmenting which contains a lot of the important data (like the menu backgrounds which you can see were missing).  There is a patch to fix this, and I think that patch is required for TI-Boy to run for the same reason, but I just got around it by simply starting that page with a different byte instead.  This couldn't possibly have happened with versions prior to 0.4.x since Axe was a single page app then.

for an unknown reason, my version of Axe Parser (0.3.3) is not error scrolling AT ALL. The source is unarchived and the only other thing installed on my calc that uses a hook is CalcUtil.

um... this is supposed to happen, right?


ram clear is useless; the only fix is deletion and replacement
furthermore, this isnt the first time it's happened

TI-84 Plus Silver Edition
2.43
PROD#: 0A-3-02-2B

this is axe .4, but i've had the same thing happen on earlier versions as well
EDIT: and here's everything in my arch, if you think it might help

Code: [Select]

apps
Axe:Bubble:Calcsys:Celtic3:DAWG:DoorsCS7:Graph3:NoteFlio:Periodic:Pyoro

vars:
like 50 pictures(using celtic3):ALCDFIX:AMID83:ASTEROID:ATTACK:BEJEWELED:BUBBLE:CALCMOD:CAVE:CONWAY:COPYBG:DESOLATE(&desdata):DK5MOS:DODGE2M:EPHALONE:FDOWNX:FISH7:FPHOENIX:FRETRCK2:FROGGUTS:GALAXAN2:GEOWARS:GPHX5:GRAYMINE:GRAYTUNL:IGO:LOTUS(&lotusdat):MARIORUN&ED:MAZE3DII:MCROHRTZ:MIRBUTN:MIRDESC:MIRNAME:MOSOKO:OMEGA:ORBIT:ORZINOID(&editor):PUYOPUYO:QWERTY:REVERSI:RUSHOUR:SERPENT2:SKY:SN00D:SNAKE:TETRISM:TRAPPED:TRON:and 100 or so progs of my own making

Did you try compiling an APP under a name that already exists? On my TI-Nspire I had the same problem happening. The workaround right now is to delete the old game APP copy then compile a new one, not overwrite. It's because Axe writes it to the wrong Flash pages, if your app already exists and it appears to overwrite one of the Axe Parser page. I believe this started when Axe became a 2 page application.

Hmm interesting, I haven't had any random crashing problems yet... I'll look into that.

Yes, the built-in subroutines are added to the Data section of the code in the order that they are first called and its mixed in around other data as well, even inline data.

Okay, I was able to duplicate the error.  It appears to only affect very large source code and it is totally random and not dependent on pass.  I seemed to only get the error when the source was archived or auto-backups were turned off but I'm not sure what the problem is yet.  It shouldn't be too hard to track down though since at least i can replicate it after about 5 compiles.

I think you're confusing user-made subroutines with built-in subroutines.  The user-made subroutines which are basically just labels are just like any other code and added inline whether they're used or not.  But the built-in subroutines like multiplication, Pt-On(), DispGraph, etc. are only added when they're needed, but not inline, they're added at the end of the program like the data to decrease the overall size of the program.