Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - 133794m3r

Pages: [1] 2
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 source is included with it or at the least it was when I got it, butthe whole thing about revsoft as far as I can tell they've dissappeared off the face of the earth as the site has long since gone from any attempt or idea of them existing.

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.

The second one does just fine, but the first seems to lock up on the "set the contrast" I tried to xfer the save file so I can get past it but it dooesn't seem to work. It gets stuck on the contrast/refresh scren Idon't know what's causing it, even attempting to unarchive evreything it still doesn't run correctly and freezes again.

The Axe Parser Project / Re: Bug Reports
« on: December 25, 2012, 08:34:53 pm »
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.)

The Axe Parser Project / Re: Bug Reports
« on: December 25, 2012, 02:05:16 am »
Yeah, I'm not surprised floating point math isn't working, because Axe doesn't have floating point math. The float{} command is only for converting between OS floats and Axe's standard 16-bit integers.

However, if you want something slightly closer to floating point math than integer math, you can use fixed point math. Standard fixed point numbers in Axe give you a range of about -128 to 128, with a precision of 1/256 (they're essentially signed integers treated as being a fraction over 256). You can find more information about both float{} usage and all the fixed point operators in the Commands.html file included in the Axe download.

It "should" be OK but now it's not giving me _any_ results that are _remotely_ accurate.

Anyway I just tried it with the "fixed point way". And it doesn't work either.
Code: [Select]
:Disp B>Dec
Expected 1, got 0.

So even though it "should" work, it's still not.

The Axe Parser Project / Re: Bug Reports
« on: December 25, 2012, 12:42:35 am »
Floating point math _isn't_ working currently.

Here's an example program.

Code: [Select]
:Disp C>Dec

Expected result.

Code: [Select]
Actual result.
Code: [Select]

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).

Axe / Re: InData like routine is never firing(even though it should)
« on: December 22, 2012, 07:14:46 pm »
It's working now, so I'm going to lock this topic, as I honestly donn't think there's much else to be said about it. My mistake was found, and thanks to all who helped.

Axe / InData like routine is never firing(even though it should)
« on: December 21, 2012, 10:23:10 pm »
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
Code: [Select]
If {{r1}}={B+{r2}}

The code below is the code that calls that subroutine.

Code: [Select]

Disp L>Dec,[i]
Pause 2000
If theta!=65535

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.

The Axe Parser Project / Re: Axiom Requests
« on: December 21, 2012, 10:18:38 pm »
OK, something that I need is an InData that actually checks the data, not just strings. InData's great and all for strings, but I need one for actual data. I've tried writing my own out, but it never seems to evaluate. I'm going to post it in the help pages, but still having that function would be greatly appreciated. Also if it returned 65535 if it wasn't found instead of 0(as the data is 0 indexed) would also be greatly appreciated.

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.

The Axe Parser Project / Re: Features Wishlist
« on: December 21, 2012, 06:31:48 pm »
Ah OK, well that's good to know then. I was talking about additional options, IE an option to make it do _even more_ optimizations. Instead of teh "faster" mode, I was talking about a slower mode, wherein it does _even more_ optimizations another pass or something. Also about the subroutines returning variables that's workable. Since I needed a way to do the InData that was actually working with data, not just strings. But since it seems to be workable, I'll be using it then. Thanks for the info everyone who's already said things here.


Something else that I'd like to see as the main parser, is a Binanry string converter. It'd be the same as the >Hex command.

Something like


Then it'd convert it into a binary string. It'd be useful for the program I'm working on, I'm planning on writing a routine to do it, but I have no doubt that if it was in the main parser it'd be way faster. Anyway that's all I can think of right now.

TI Z80 / Re: TokenIDE - TI-BASIC IDE
« on: December 21, 2012, 12:45:46 am »
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.

The Axe Parser Project / Re: Features Wishlist
« on: December 20, 2012, 10:57:03 pm »
I'm probably a crazy person. so please ignore this if I am one of those. The first pass I guess is where it converts it into assembler, and then the second is optimizations? Something I'd like is for it do another pass of peephole optimizations, but make it non-default so that if someone's crazy/really needs whatever additional  little things it can do, it'd be added, by holding some button, like Mode when compiling to make it do another round of optimizing/shrinking. Other than that, that's all that I can think of right now as far as my "would like to see" list. Also, I imagine that Axe is already using the "full" 15mhz on the ti-84s, but if it isn't, I'd love for it to start using it. I imagine it is(as the compile times are rather quick, for everything I've tested/wrote), but if not I'd love for it to be there.

One other thing that I'd love to have is for it to have the subroutines be able to return a value as the built in functions of the calculator/axe ones do. As this'd help make my code a tad bit more clean, there's already the option of giving subroutines variables, but being able to return one would be uber-awesome. I'm not even talking about passing around ptrs with mass amounts of memory, just some way to return a 2byte value would be uber-awesome/useful for people like me who are used to c.

Axe / Re: Axe Q&A
« on: December 20, 2012, 09:02:43 pm »
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.)

Pages: [1] 2