MaxCoderz

Maybe instead of including all of ti83plus.inc, you could trim it down to the fundamentals. Like bcalls for keypresses and whatnot. If the slightest ASM mistake is gonna wipe out the whole calc each time, nobody is going to try anything too elaborate anyway. Unless they're a daredevil. That's my 2 maxcoins.

VAT ROMcalls? i think those are the most useful imho. Besides that, I've never used ROM calls, just ion routines and direct input.

then again, I've only coded ASM once in a very blue moon.

What if you could connect your calculator to a palm? That way you could code asm on the palm, send to the calculator. *shrug*

Or you could get a life so you don't even have the time or feel the need to code assembly on the go

Timendus wrote:Or you could get a life so you don't even have the time or feel the need to code assembly on the go

then who would make any calculator programs if we all got a life?

Who would want any?

Timendus wrote:Who would want any?

people who are bored in math or science class. I've tried it, carying a gameboy into physics class is not nearly as well recieved as playing calculator games. I played calc games for most of the physics classes this year, with no problem. same in math class.

doesn't seem to practical to me

The only thing I don't like about coding on the comp is that it hurts my eyes after awhile and I get really tired.

OMFG TASM ON CALC!!!
ITS THE 1ST APRIL ALL OVER AGAIN!!


I am going to try this APP ASAP.

ASM on my TI.... oh boy... RAM restore will come in hand!!

you know whats wrong with this..
.db will cause an error, allways. try it.
any immediate value must be decimal (it has a hexadecimal converter.. which doesnt work)
it takes forever, and it isnt even optimized
i asked that guy for the source for bugfixes, he gave it, and it wasnt optimised either, not that its a problem.. but still..
im going to try and fix it..

Well, I'd say a large issue is that developing on calc means that your source is more prone to RAM clears. Archiving and unarchiving your source before/after you want to test seems like a pain. Plus, my source files for simple routines are at least 10k. Definitely not calc-friendly.

King Harold wrote:you know whats wrong with this..
.db will cause an error, allways. try it.
any immediate value must be decimal (it has a hexadecimal converter.. which doesnt work)
it takes forever, and it isnt even optimized
i asked that guy for the source for bugfixes, he gave it, and it wasnt optimised either, not that its a problem.. but still..
im going to try and fix it..

OMG I LOVE YOU!!!!! IF YOU GET THIS YOU WILL BE A HERO FOR GEEKS EVERYWHERE!!!

Well, I'd say a large issue is that developing on calc means that your source is more prone to RAM clears. Archiving and unarchiving your source before/after you want to test seems like a pain. Plus, my source files for simple routines are at least 10k. Definitely not calc-friendly.

CrunchyOS? Doesnt clear your RAM!

Or i could just have it archive the source right after compiling it.. no big deal..
if someone would like to explain in easy short words how to use _FlashtoRam and _Pagedget then i could make it compile archived source..

ps: expect a Basic program using the old tasm-on-calc ZTASM but a better Basic part sometime during next week (if im not ill again)

Yes, if a program crashes, crunchy os may be able to stop it from clearing the ram(usually, but it doesn't always work). Even if it doesn't, the program you are running will not be corrupted or deleted if it crashes.