Documentation says pointer to the "string structure". You're probably right it's an OS variable. Oops

Right, and you can also do it by modifying some data in the program. (Note that only needs to Buff(8 ), though, and there's no need to pre-fill it with zeros)
Edit: Tested and works

You also forgot the simple one: programmer is busy/distracted/lazy
And I wasn't under the impression calc84 had lost the source--I thought that was the Nspire 83+ emulator project. Could be wrong, though.
Also, at least to me, "savestate" means the ability to store (and restore) the complete game state at any point--in the middle of a level, for example--not just when the game saves. Supporting multiple savestates is a typical feature. TI-Boy, at least as far as I can tell by the documentation, doesn't have this. You're probably thinking of just regular saving, which I agree it would be silly for TI-Boy not to have.
Also, I don't want to assume anything, but your post does sound frustrated and perhaps even somewhat aggressive/attacking towards TheCoder1998 and perhaps the forum in general. Hopefully you didn't mean it that way .

Quote from: calcdude84se on January 22, 2014, 09:47:57 pm

Quote from: hking1 on January 22, 2014, 09:41:48 pm

note this does not work for nspire series so technically not all ti calculators

While we're being technical, it should work for the 84+SE emulator that's on some Nspires . (Though you could argue it's not an Nspire anymore )

however i am having trouble getting a rom for 84 se since wabbitemu for mac does not provide the rom automatically
if u can tell me a way that would be awesome

Well, the emulator I mention is built into the Nspire OSes that have them (and is activated when you swap the keyboards).
If the Mac version of WabbitEmu is anything like the others, when you start it up for the first time (or if you find it again in the menus) it should show a dialog providing you several ways to get a ROM. By far the easiest if you don't already have one is to use the FOSS bootcode and download the OS from the internet.
Also, to avoid derailing this topic, I'd recommend creating another topic if you have any further questions.

This is how for loops usually work:

Code: [Select]

:For(<variable>,<start>,<end>)
:<do something>
:End<variable> is a real variable (=uppercase character or one of the variables from the finance app).
At the start of the loop, that variable is set to the <start> value. Then, the code inside the loop is executed. If the variable is smaller than the <end> value, it gets incremented (1 is added to it), and the code in the loop is executed again. This keeps happening untill the variable is greater than or equal to the <end> value.

TI-BASIC for-loops work slightly differently. (I say after verifying this to make sure I wouldn't make an idiot of myself by incorrectly correcting you )
Namely, when <do something> is finished, first <variable> is incremented, and then if it is less than or equal to <end>, <do something> gets executed again. Only when the incremented <variable> is greater than <end> does the loop end.
Admittedly, this only produces different results in two ways. It loops floor(<end>-<start>)+1 instead of ceil(<end>-<start>)+1 times, which only matters when <end>-<start> is not integral. And <variable> ends up being floor(<end>-<start>)+<start>+1 (equal to floor(<end>)+1 when <start> is integral, and <end>+1 when both are), not ceil(<end>-<start>)+<start> (equal to ceil(<end>) when <start> is integral, and <end> when both are).
TL;DR: for the most common use (<start> and <end> integral, <end> >= <start>), the main difference is that <variable> ends up as <end>+1, not <end>.
(This is likely more detail than is important, and hopefully it's not too confusing to anyone, but it's nice to set the record straight. Naturally, no offense meant to you, ben_g )
Also, as a reference to UoaU and others who want to read the whole thing and might be slightly confused: ceil/ceiling rounds up to the nearest integer (so ceil(-1.3)=-1, ceil(3)=3, and ceil(4.2)=5) and floor rounds down to the nearest integer (so floor(-1.3)=-2, floor(3)=3, and floor(4.2)=4). An integer is a number without a fractional part (ceil and floor leave these alone).

Holy fuck, it's been three years (and one week). To be brief, it's on permanent hold. Sorry (Xeda reminds me it's in my signature, so I've taken it out)
I'm definitely still interested, at least theoretically, in making a TI-83+ series OS, with goals similar to the ones I've named for this project.
What happened, mainly, was that I was never sure how to achieve those goals while maintaining efficiency. (To save you from looking it up, my main goals were to have unlimited extensibility and abstraction. I don't know how much programming you've done, but unlimited extensibility, as I envision it, requires theoretical support for arbitrary-precision numbers (or at least 4-byte ones), which are not efficient. And unlimited abstraction requires that everything be indirected; I, again, don't know if you've done any assembly programming, but bcalls are horrendously slow in comparison to doing whatever they do directly, and I'm basically proposing making every external call a bcall.)
Of course, all this slowness is theoretical--the system never got to a state where I could see it for myself--but it was enough to prevent me from writing code. In retrospect, I do think I worried a bit too much, and there likely would have been optimizations available to help some (KnightOS's use of SMC to make relocation efficient is one example). After all, the whole thing is a hobby project, and it's not like blazing fast performance was ever an achievable goal . (To really give up on performance, maybe I should just make the OS a LISP interpreter )
Unfortunately, I'm now busy with other things. I've just talked myself back into doing this, which is unfortunate because I'm not sure I have the time. I think I will try this again, but it will be quite slowly. (Admittedly, anybody who's been following this has been doing so for years, so I think they can be patient ). With luck, there'll be an update from me here within a month.
(And as a plus, if I design it correctly, it should be easy to optimize, at least in parts, due to the very separated nature of it. So I'm feeling optimistic again)

It would only require me to change from using 1 byte for the size to 2 bytes.

My main worry was that that sort of thing can sometimes completely mess with register allocation and such. Good to hear that that sounds like it wouldn't be a problem.

I could probably add another type of int and float that is basically max precision

That would be cool indeed.
I already have a potential use for this (which is straightforward enough that doing it in ASM wouldn't be too awful, but a language that would make it more natural is of course a good thing), but I'd also need key input, bitmath, direct writing to the gbuf, and loops. So eventually. (Maybe I'll write it in ASM first if I have the time) Good graphical display of mathematical things is awesome.