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 - calcdude84se

Pages: 1 [2] 3 4 ... 161
All right, fixed code time. Now requires 10 bytes of RAM at L1 'cause I don't feel like special-casing the length-8 case.
Code: [Select]
Asm(EB3600) .Puts 0 at the end. Assumes DE=Y+L after Copy(X,Y,L). Else just do 0->{L1+1+L}, where L is stored from the call to min(
If GetCalc(L1,Y1
Edit: Works, and for the right reasons this time. :D

Documentation says pointer to the "string structure". You're probably right it's an OS variable. Oops :(
* calcdude gets to rewriting

Nope. The string pointed to by input is null-terminated, which is copied over (unless it's 8 chars, but that's okay) and that's how GetCalc( reads it as well. And if the name is 8 characters long, it doesn't need a null.
Edit: Tested it like this; it worked:
Code: [Select]
Fill(L1+1,9,85 .Garbage
If GetCalc(L1,Y1
Disp "AWW...
The names, in order, were ASAVEPIC and DCS7.
Edit: For posterity: this code is wrong, mainly because I forgot how input works. It often gets the right result, but it's a coincidence that it does.

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

I'm assuming you might want to read from Archive. If so, this code should work: (Note: requires 9 bytes of RAM, here assumed to be at L1)
Code: [Select]
21->{L1} .The 21 means appvar
If GetCalc(L1,Y1)
.Variable exists, Y1 is the relevant file
.Variable doesn't exist
I'm gonna test this, but it ought to be good.
Edit: For posterity: this code is wrong, mainly because I forgot how input works. It often gets the right result, but it's a coincidence that it does.

You also forgot the simple one: programmer is busy/distracted/lazy :P
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 :).

Site Feedback and Questions / Re: "._."
« on: January 23, 2014, 01:35:36 pm »
I'm okay with (mild use of) animated smileys as long as they don't change color <_<. I find that that gets really distracting and hence annoying. Thankfully, we only have two ;).
(Alternatively, would it be possible to add an option in the profile settings to disable parsing smileys? I don't personally find graphical smileys particularly necessary.)
Edit: 2222 posts! That's 2*11*101 factored, and $8AE in hex, neither of which is particularly notable :P

TI-BASIC / Re: basic clock program for any ti caclulator
« on: January 22, 2014, 10:43:39 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 :P)

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.

TI-BASIC / Re: basic clock program for any ti caclulator
« on: January 22, 2014, 09:47:57 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 :P)
Thanks that helps, I will post a revised version later
Good luck! I'm sure someone will be able to help you more at that point if you have any questions :)

TI-BASIC / Re: basic clock program for any ti caclulator
« on: January 22, 2014, 09:40:28 pm »
This is how for loops usually work:
Code: [Select]
:<do something>
<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 x.x)
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).

TI Z80 / Re: LangZ80
« on: January 19, 2014, 01:07:34 pm »
Well, for what I'm thinking of, I mean being able to write 12 bytes of an int to memory corresponding to a row on the LCD.
Congrats on getting variables working properly; it sounded difficult. :)

TI Z80 / Re: PartesOS (or YATPOS :P)
« on: January 19, 2014, 12:56:09 pm »
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 :P)
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 :P). 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)

Axe / Re: Axe Q&A
« on: January 18, 2014, 11:59:53 pm »
So with an 8 by 8 sprite you use Pt-Change() to draw it inverted. How do you do that with a 16 by 16?
Since Axe doesn't have any 16x16 sprite routines (at least as far as I could tell according to the official documentation), you have to do it by drawing four 8x8 sprites. So if Pic1 is the top-left corner of the 16x16 sprite, Pic1+8 is the top-right, +16 the bottom-left, and +24 the bottom-right, then you'd want to do something like this (assuming drawing to X,Y):
Code: [Select]

TI Z80 / Re: LangZ80
« on: January 18, 2014, 10:33:39 pm »
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 :P
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.

Computer Projects and Ideas / Re: A new scripting language for Linux
« on: January 18, 2014, 09:16:16 pm »
I am really curious if some classic BASIC games will run fine even with no modifications? I remember once I made an Axe program that almost ran identically with no change (except inverted X coordinates).
Basically with the PC interpreter acting as a TI-BASIC interpreter? That would be neat. But Juju did say he wouldn't be emulating the calculator screen. (Which is IMO a perfectly reasonable decision. The goal here isn't actually to create TI-BASIC again)
But still, a calculator TI-BASIC compatibility mode could be cool (Even if it means I have to resize my terminal to 16x8 for the homescreen :P)

Pages: 1 [2] 3 4 ... 161