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] 5 6 ... 161
46
« on: July 27, 2012, 11:28:35 pm »
That probably won't do what he wants, though. The token hook is called whenever the OS needs to display a token. A TSR interrupt is called whenever an interrupt triggers. Not the same thing at all. Concerning a TSR interrupt, if the 83 OS is sufficiently similar to the 83+ OS, then various things that really shouldn't (like viewing the graph screen by pressing [GRAPH]) will switch the processor back to IM1, killing your interrupt. Probably not very stable 
47
« on: July 27, 2012, 07:12:57 pm »
USB flash drives are slower to use than flash. Though if you're wanting to emulate the i386, I'm not sure it really matters, as it is already far faster to begin with  An interesting demonstration, though!
48
« on: July 26, 2012, 10:15:55 pm »
in theory, I could use 3 16KB ramdisks, with archive swapping.
Theoretically, yes, but any program that routinely uses all three areas of memory will be quite slow (writing and erasing Flash is not very quick), plus it will wear out the Flash chip pretty quickly. Glad that you could think of the idea, but in general, if there's not enough RAM, you just can't do it.
49
« on: July 24, 2012, 11:58:51 pm »
Reminds me of CalcDOS - an x86 Emulator. (Only linked for grins and giggles, as the program isn't very functional.) I think it's an interesting general question what old hardware we can readily emulate on the 83+ series. I don't know enough to suggest any candidates, but I'm sure something interesting could be done. 15MHz is relatively powerful. Even the 83+'s 6.
50
« on: July 06, 2012, 02:52:17 pm »
I've done it before, but it's not something I do very often. My tool of choice is Flashbook. It creates a stand-alone app, supports sizes up to all of Flash, and supports compression, too. For anyone interested in lojban, I created a version of the reference guide. It's attached to this post. (Warning: it comes in at about 600KB, as I recall, probably making it 83+SE/84+SE only)
51
« on: July 06, 2012, 02:50:48 am »
The OP "registers" are a set of memory areas that are used as operands by the OS's floating point routines. Unless you need floating point, there shouldn't be a need to explicitly deal with them.
If you want to do math with larger integers, you basically need to write the routines yourself (precluding a library/axiom already having been written. I don't follow Axe too much.).
For example, to add the number BA (formed from variables A and B) to DC, and store the result back to BA, you could do something like A+C->A<C+B+D->B, where -> is the STO> symbol.
An easier-to-follow variation goes like this:
A+C->A
If A<C
B+D->B
Else
B+D+1->B
End
52
« on: July 02, 2012, 04:56:12 pm »
Wouldn't it be possible to get the font sprites directly from the OS? I have no idea where they are located in the OS ROM, but they're surely there.
53
« on: June 27, 2012, 11:59:28 pm »
The "fancy GetCalc statement" calculates the corresponding address in the original. So yes, it can be used to update in the original, and you can also update in the running copy. There shouldn't be a need to always keep the two in sync, though.
I'm not sure how this works when running from a shell. I'm under the impression that most shells will copy (from Archive) or move (from RAM) the program to the appropriate location, and this would yield the program's (or the copy's, if from Archive) name in OP1. Thus, it will just update in-place. However, I'm not sure if this is documented, so unless you can confirm it in Ion, MirageOS, DoorsCS, etc., it would be best not to have code like Deep's in shell versions.
54
« on: June 27, 2012, 09:41:59 pm »
A shell manages this for you; you change it in the running copy and the change gets copied back. Most people will at least have Ion, if not MirageOS, DCS, zStart, or something else. Just use GDB3 or whatever the equivalent is in you program.
If for some reason you want it to work without a shell (and not to work with a shell), to get the appropriate offset you just select the appropriate address (i.e., replace GDB3 with whatever is applicable); that's it.
55
« on: June 27, 2012, 04:55:55 pm »
When the TI-OS runs an ASM program, it copies it to $9D95 and deletes the copy when it's done. Thus, any changes to the running copy don't do anything. What Deep's code does is find the original program (not the running copy) and get the address of the high score from there.
Note that this has the possibility of not working as intended when running from a shell.
If you're curious how Deep's code works, here's a quick outline:
GetCalc( takes the address of a string with a variable name and returns the address of the variable's data. When the TI-OS runs a program, the name of the program is copied to OP1, whose address is $8478. GDB3-E9D93 is the offset to the high-score value from the start of the ASM program header. This is added to the address given by GetCalc(, and the sum is the location of the high-score value in the original copy of the program.
56
« on: June 24, 2012, 01:53:25 pm »
Would this also be possible for the 84+?
No, because the 84+'s buffer is only 94x64.
Actually, it's 120x64. I'm sure that a program that reads LCD commands from the USB would be able to display that whole area.
Actually, it depends on the calculator. Mine, as I've determined from several tests, is 96x64. The most important result is that, when the LCD is in Y-autoincrement mode, after the 12th/16th column (8-/6-bit mode, respectively) it wraps back to the first column, not an invisible one offscreen. Mine's also the one with the extra commands to flip the display, which gives me the impression it's a different driver.
57
« on: April 14, 2012, 10:04:42 pm »
I'm posting on behalf of HavokDelt on IRC, who doesn't currently have access to a GUI to be able to post. I'm going to pretend it's my problem for easier reading.
So, I want to create a slider that will draw the normal line to a parametric curve at a given time.
My current setup is this: a and b are y and x for the parametric curve, and are defined in terms of t. The variable y and x themselves represent the line. byx represents the slope of the tangent line, calculated as "da/dt*(db/dt)^-1". So, the line is "y=a+byx^-1*(x-b)".
The problem is this: while byx gives the expression for the derivative just fine when t is not defined, when the slider is in use t is given a numeric value. Because of that, a and b are no longer expressions, but values, so da/dt and db/dt are both 0, and byx is undefined.
Now, another calculator I have has an Exchange function that replaces one variable with another, say t with k, and I can use it to make a similar thing work there.
But how can I do this on the Nspire?
58
« on: April 09, 2012, 03:31:43 pm »
The variable-less version of For( doesn't have its opening parenthesis closed by a newline.
As a result, this simple test program fails to compile:
For(10
End
59
« on: April 08, 2012, 04:06:10 pm »
If exactly one number will be zero and the numbers aren't sorted in any way, I'm pretty sure the best way is to go through them with a variable containing the minimum value, while ignoring zeroes.
Here, for example, is some code that will give the minimum non-zero value in the first 100 bytes of L1 in M (And -1 if they're all 0):
-1->M
L1->X
For(100
If ({X}->V<M)?V=/=0
V->M
End
X++
EndThere's probably a more optimized way to write that, but it should work.
If there could be more than one zero, the essence of what you have to do is have a flag that records whether you've already encountered one zero.
Edit: Runer112 wins by far. The method I've proposed would work better across lots of values (perhaps at least 10) than across 4.
60
« on: April 08, 2012, 11:49:22 am »
I suppose you could use bit arithmetic with a pointer to a Pt-Get('ed sprite. I'm not too clear on how that would work though.
If it's byte-aligned, he could even work with the bytes directly, instead of using Pt-Get(. With that said, the fastest way to find the number of set bits in a byte (which is a necessary part of this) is almost certainly a look-up table. Yes, it's 256 bytes, but it's far faster than any bit arithmetic you can do.
Pages: 1 2 3 [4] 5 6 ... 161
|
Show Posts