Ah OK then, I'll try to message them there/on codeplex then and see if the core emulation code has any chance of getting updated. At the least to the 3ds homerew.

The sequel one works just fine and I know that it's not that up to date, even though it's 1.0 it doesn't run as fast as I'd like for it to be Basically it runs ~20% slower than on my actual calc(the second one), and the xlib ti-basic gaems with the 2x speed mode run almost as fast as on the calc itself. I'm sure part of it is that the ds isn't that fast really at all. And I was hoping to have a simple way of going at it, but that's the one game that gets stuck on the "set contrast/refresh rate" screen. The second one runs just fine andseemingly at full speed. Both are the axe versions, I'd not dare attempt to run the original basic ones due to how slow oher basic games run.

OK, it _has_ to be a bug then. I'm using Axe 1.2.1 and changing the values to "1.0, and 10.0" makes the number the _same_ 250, which means that, according to you, there's a rounding error(for some reason). Also the thing that got me into this whole crazy thing in the first place was some "big"(at least I think it is) numbers not working right in Axe.

It was (2/10)*65535. I was expecting a whole number 13,107.  But, it never turns into that value... ever. I doubt Axe would be able to do it right now since you're saying it's all 256ths and 65535 256ths wouldn't be the 65535 value(a maximum for the total range in the range encoder I was working), just isn't working at all. I tried the fixed point math, it doesn't work either, nothing seems to work.

So since Axe can't do floating point math, and since fixed point(isn't working either), I don't know what to do right now. Since it's just not working(at all), and also since fixed point only works with values -128 to 128. The value I get is 65485(which is almost 1.0*65535), and it well should've been 0.2(51/256ths clearly close enough), but somehow that gets converted into nearly 1.0 which makes no sense to me(at the moment) but I imagine it's something with the parser. I'm beginning to think that I should just give up on Axe, as it's promises were too great. Even the math isn't working as one would think.

Edit: Basically, I wanted to do a simple rouguelike with psuedo-procedural generated content. But I wanted a way to compress the premade "rooms" and other data, in range encoding(seemed like a perfect first program... at least has always worked just fine for all of my other language excursions). Well to be honest, I normally do LZW, as the first one, but axe it looked to be requiring way too much work. But now I don't even know if range encoding will even work, because that's the _only_ spot I have to use non integers, and of course the one spot where I need some sort of non-whole number math, it doesn't work... Basically even if I don't do "real numers" it says it's 0. Even though (2/10)*65535 should be that 13,107. This is _only_ spot I needed non integer math, and of course it's not going to work.

Well... I guess there's two spots, the part where I calculate the share of the range, and then once again when I'm running over the data... but either way I had always used 65535(or some similar "big") number as I don't need super-duper precision. I just needed a way to do fixed point during that part. Then a single operation during the second part too. I was planning on just storing the counts(x bits) one after another and then recalculating the whole range later on. But anyway yeah, 3 decimal points _should_ be way more than enough.(with the whole range I'm using I just need for the values at the end to add up to the whole thing), and then of course make sure that the ranges work right(for the final two byte range value).

That's all I wanted to say here about it, I may go to the subroutine thread and asking for a fixed point math routine that actually does fixed point math as one would expect(even with the rounding errors.)

Floating point math _isn't_ working currently.

Here's an example program.

:.TEST
:2/10->Float{C}
:C*10->C
:Float{C}
:Disp C>Dec
Expected result.

1
Done
Actual result.
0
Done
I've tried this multiple times and apparently floating point math doesn't work at all right now. I can't understand it but it's just not, at all. This is exactly accordingn to the commands documenation, it should result in the value being 1. It doesn't though, which makes me not understand why it's even there right now then. I've tried it on my ti-84plus se calculator running 2.43 with Axe 1.2.1, and I've also tried it with tilem2 running a 2.43 rom with the same specs(rom built by wabbitemu), and also a literal dump of my calculator. I've also tried it on an emulated ti-83plus se. None of them give the expected result(according to the syntax as setup in the commands list/documentation).

The code below is supposed to search through the data, and then if it finds the byte given to it, in the clump of data(r2) it'll return it's index(0 based). Otherwise it should have 65535 be stored as the
.SEARCH
Lbl SEARCH
65535->theta
255->X
For(B,0,X)
If {{r1}}={B+{r2}}
B->theta
255->X
Return
End
End
Return

The code below is the code that calls that subroutine.

.RC1

"SILLY STRING"->Str1
length(Str1)->L
Disp L>Dec,[i]
Pause 2000
0-Z
For(A,0,768)
0->{L1+A}
End
For(A,0,12)
SEARCH({Str1+A},L1)->theta
If theta!=65535
{L1+theta}^^r++
Else
{Str1+A}->{L1+A}
0->{A+255+L1}^^r
Z+1->Z
End
End
prgmSEARCH
I've tried debuggingn it by displaying the two values, and they _should_ match but it never seems to fire off right, and I have no idea why. I never seem to get a single byte to match a single other byte in the data. Even when I _know_ it should be in there and I can clearly see it.

Ah well, I can't wait for it to be done then! I'd love to be able to program faster on my calc(especially when I'm waiting around w/o a computer), sinec I found TokenIDE, on calc programming has gotten a tad bit too slow for my tastes.

OK, quick question... am I crazy... or is the last time it was compiled was december 5th? I'm just making sure I'm running the latest version. Btw, absolutely amazing program, like seriously, I am so glad this thing exists. Being able to type out code on my calculator then be able to open it in Tilem2, and see if it works is _sooo_ much faster than writing it on my calc, and then compiling it, then running it. Effeciency has gone up by like a bajillion.

Also a feature that I'd suggest for the future is when you're clicking on the "reference" when you type a letter, jump to that letter's selection. Ala the catalog on the calculator. This'd make it much better/faster for me when I'm trying to figure out how you called a token, so I can double click it faster. That's probably the only feature that I _really_ want. That and projects working(since that feature sounds like an awesome one too). Finally, the last thing I can think of(I've not checked it yet), is that if you click on a prgrmSOMETHING, it'll take you to that program's tab(if it's in the same directory). Those are my feature requests, I don't know what your roadmap is, or if you've already had those things in the roadmap, I can't wait, if not I'd love to see them in it. I don't speak c#, so I can't help at all, but anyway keep it up, this is an awesome project.

Axe no longer uses the last 54 bytes as of Axe 1.2.0, so feel free to use L1 to 768 bytes. L2 is more or less stable for the first 800 bytes or so, but remember to run ClrDraw(L2) at the end of your program. Volatility doesn't refer to whether or not your data will get messed up during the program runtime, it refers to how screwed up bits of your OS will get after you quit out of the program (L2 has the chance of messing up tables and such).

Ah OK, that's really good to know then. And hmm that's itneresting about L2 as it says only 512bytes, but anyway thanks for the information.  I'd upvote or thank, or whatever they call it on here but I can't seem to find it... Now onto finishing up the range encoder!(Worst case scenario, estimated as a reduction of ~16% on 768byte thing.)