hmm...I'm pretty sure I'm not compiling it right...devpac8x doesn't work for me for some reason so I've been using tasm to convert it into binary then objhex to convert into hex then graph link to convert it into 8xp. Is there a better way to do this?

Edit: I've also used latenite's compiler/debugger (brass and pindurTI) which gives me a much smaller file in binary which gives me an "INVALID" error when trying to run it

I use the IDE from RevSoft. The linux version, but I think has been built for Windows too.

You are using Asm(prgmXXXX to run your program, right?

Wait, do you have a TI-83 or a TI-83+? I thought you were using an 83+, but you said you used objhex, and last I checked that created ASCII-encoded hex such as Send(9prgm uses on the TI-83.

I usually try both asm(AsmPrgm#### and just running it normally just in case although .db $BB,6D should add in the asm(AsmPrgm


I am using an 83+, the tutorial I learned asm from had me use objhex and it worked before
[url]
http://www.ftp83plus.net/Tutorials/contentA.htm
[/url]

Edit: By the way, is there a program that will tell you how large a block of data will compile to? I'm planning on making this an app when I'd done (mainly because it'll be much larger than 24k) and I'll need to cut it up into 16k pages

Never mind, I didn't realize that there was a cap on the size of the program other then the amount of ram on the calculator.

More specifically, there is a capon the size of the executable code (since you cant execute past $C000). You are allowed to have the data section of the program past that boundary.

How is that implemented, does anyone know? That sounds like a feature just being added to new hardware and software on PCs called in that case data execution prevention or dep, is this similar enough that one could write a new OS with dep like features or is this a hardware limitation?

It's a hardware limitation, though it's actually tied to the RAM page normally swapped into $c000-$ffff, rather than the program counter being in that range.